Index-only Scan может использоваться, если в нем есть все поля из таблицы, которые нужны запросу (если чего-то не хватает, то придется идти в таблицу, а это уже не Index-only).
А будет использоваться или нет — это зависит от решения планировщика. Собственно, планировщик поглядит на карту видимости, чтобы скорректировать стоимость в зависимости от того, какой процент страниц сейчас в карте видимости.
Поскольку картинка взята из моей книги, позволю себе ответить.
Стоимость последовательного сканирования — константа, мы просто читаем всю таблицу.
Index-only Scan — в хорошем случае, когда все страницы в карте видимости — читает только индекс. Если индекс меньше таблицы (а обычно так и бывает), то прочитать даже весь индекс целиком будет эффективнее.
Но вот в плохом случае, когда страниц нет в карте видимости, Index-only Scan превращается в тыкву, то есть в обычный Index San. А это уже всяко дороже, чем Seq Scan.
Тут вот какой момент, раз уж речь о технических статьях. Что, если мы хотим сначала показать таблицу и insert-ы, а потом (в отдельных div-ах) показывать всякие запросы к этой таблице, не повторяя каждый раз вставку? Вроде это довольно-таки базовый сценарий для статей.
Нет, параллельно continue() вызывать нельзя, и не очень понятно зачем: если нужно продолжить генерацию с того момента, где она остановилась, надо просто вызвать continue() один раз.
Если я правильно понимаю идею - готовый стендовый тест нагрузочного тестирования ?
Интересно было бы попробовать генератор в таком качестве. Не уверен, насколько создаваемая им нагрузка показательна, но она всяко разнообразнее pgbench-а. Журналирование только надо вернуть, оно убрано для скорости.
Например, частая ошибка — это добавить новое поле в большую таблицу с дефолтным значением. Это будет долгая блокирующая операция, так как PostgreSQL будет копировать дефолтное значение во все записи в таблице.
Да уж семь лет как не блокирует. Кому нужен очередной сборник мифов из интернета?
А вот это так просто просто шедевр:
Сгенерируйте побольше данных в локальной БД для проверки индексов.
Было ж уже: https://habr.com/ru/news/1005734/
Истинно так.
Правильно будет написать «число страниц, которые запрос превратил из чистых в грязные» (это не одно и то же), но если по таким мелочам придираться...
Index-only Scan может использоваться, если в нем есть все поля из таблицы, которые нужны запросу (если чего-то не хватает, то придется идти в таблицу, а это уже не Index-only).
А будет использоваться или нет — это зависит от решения планировщика. Собственно, планировщик поглядит на карту видимости, чтобы скорректировать стоимость в зависимости от того, какой процент страниц сейчас в карте видимости.
Поскольку картинка взята из моей книги, позволю себе ответить.
Стоимость последовательного сканирования — константа, мы просто читаем всю таблицу.
Index-only Scan — в хорошем случае, когда все страницы в карте видимости — читает только индекс. Если индекс меньше таблицы (а обычно так и бывает), то прочитать даже весь индекс целиком будет эффективнее.
Но вот в плохом случае, когда страниц нет в карте видимости, Index-only Scan превращается в тыкву, то есть в обычный Index San. А это уже всяко дороже, чем Seq Scan.
Потому что страницы уже грязные.
Справедливости ради, и в CTE можно написать
base.*. Тогда и вложенности не будет, и догадываться «что хотел сказать автор» не придется.К сожалению, не решается. Пока весь DO не отработает, статистика не обновится (даже если внутри много транзакций, а не одна).
...у вас на картинке из original wide table получился «оригинальный широкий стол», поздравляю.
И слетела шляпа.
Тут вот какой момент, раз уж речь о технических статьях. Что, если мы хотим сначала показать таблицу и insert-ы, а потом (в отдельных div-ах) показывать всякие запросы к этой таблице, не повторяя каждый раз вставку? Вроде это довольно-таки базовый сценарий для статей.
Штука интересная. А начальное состояние базы можно подсунуть?
Нет, параллельно continue() вызывать нельзя, и не очень понятно зачем: если нужно продолжить генерацию с того момента, где она остановилась, надо просто вызвать continue() один раз.
Спасибо, подумаем! В книге, конечно же, есть прямая ссылка на нужный файл, но до этого места, видимо, никто не дочитывает (:
Можно, только чуть иначе. После первой генерации надо вызывать continue() и увеличивать конечную дату на 10 минут.
По второму вопросу - да, пишет в demo, но если базу нужно выгрузить (чтобы потом куда-нибудь загрузить), то нужно экспортировать.
Интересно было бы попробовать генератор в таком качестве. Не уверен, насколько создаваемая им нагрузка показательна, но она всяко разнообразнее pgbench-а. Журналирование только надо вернуть, оно убрано для скорости.
Рад, что книга нравится! Не уверен, что успею переделать примеры для 18-й версии, но вообще это в планах, да.
Да уж семь лет как не блокирует. Кому нужен очередной сборник мифов из интернета?
А вот это так просто просто шедевр:
А часто встречается такой стиль в дикой природе? Мне как-то совсем не попадался.
Вот кстати да, возможно это привычка с других систем. В Оракле boolean тоже никогда не было в базе, его добавили совсем недавно.