Нет, параллельно continue() вызывать нельзя, и не очень понятно зачем: если нужно продолжить генерацию с того момента, где она остановилась, надо просто вызвать continue() один раз.
Если я правильно понимаю идею - готовый стендовый тест нагрузочного тестирования ?
Интересно было бы попробовать генератор в таком качестве. Не уверен, насколько создаваемая им нагрузка показательна, но она всяко разнообразнее pgbench-а. Журналирование только надо вернуть, оно убрано для скорости.
Например, частая ошибка — это добавить новое поле в большую таблицу с дефолтным значением. Это будет долгая блокирующая операция, так как PostgreSQL будет копировать дефолтное значение во все записи в таблице.
Да уж семь лет как не блокирует. Кому нужен очередной сборник мифов из интернета?
А вот это так просто просто шедевр:
Сгенерируйте побольше данных в локальной БД для проверки индексов.
Всегда было интересно, почему на SQL так часто пишут is_active = true, хотя логично же просто is_active, как в любом нормальном языке программирования.
Нет, параллельно continue() вызывать нельзя, и не очень понятно зачем: если нужно продолжить генерацию с того момента, где она остановилась, надо просто вызвать continue() один раз.
Спасибо, подумаем! В книге, конечно же, есть прямая ссылка на нужный файл, но до этого места, видимо, никто не дочитывает (:
Можно, только чуть иначе. После первой генерации надо вызывать continue() и увеличивать конечную дату на 10 минут.
По второму вопросу - да, пишет в demo, но если базу нужно выгрузить (чтобы потом куда-нибудь загрузить), то нужно экспортировать.
Интересно было бы попробовать генератор в таком качестве. Не уверен, насколько создаваемая им нагрузка показательна, но она всяко разнообразнее pgbench-а. Журналирование только надо вернуть, оно убрано для скорости.
Рад, что книга нравится! Не уверен, что успею переделать примеры для 18-й версии, но вообще это в планах, да.
Да уж семь лет как не блокирует. Кому нужен очередной сборник мифов из интернета?
А вот это так просто просто шедевр:
А часто встречается такой стиль в дикой природе? Мне как-то совсем не попадался.
Вот кстати да, возможно это привычка с других систем. В Оракле boolean тоже никогда не было в базе, его добавили совсем недавно.
Так ведь
fieldиfield = trueэквивалентны и в троичной логике.Всегда было интересно, почему на SQL так часто пишут
is_active = true, хотя логично же простоis_active, как в любом нормальном языке программирования.Больше скажу: неравнодушные к типографике не ленятся и — написать.
Учёный изнасиловал журналиста.
Если упростить до одной фразы: главное — процесс, а не результат.
Ну давайте сравним, что ли. Ткнул почти наугад. Оригинал:
Перевод 1:
Перевод 2:
Спасибо, я лучше второй почитаю.
Вот только даже 12-я версия уже не поддерживается. Зачем сейчас что-то, кроме SQL/JSON — большая загадка.
IBM 701 — это 1953-й год. В 69-м совсем другие были технологии.
Всегда пожалуйста! Расскажите, Никита, как пришла в голову такая идея и главное — как удалось это отладить? Я долго разбирался (:
Тут, увы, все смешано. Например, колоночное и построчное хранение — тоже перпендикулярная к SQL характеристика.
Красиво!
Да, но если заменить 5 и 3 на другие числа, может получиться уже не так привлекательно (: