Андрей, иной раз изменения не точечные, а довольно обширные - будет месиво из разных шрифтов, а их и сейчас уже немало. А еще кто-то может пропустить пару версий, как быть ему? В общем, пока лучший вариант - искать по тексту v.18.
Index-only Scan может использоваться, если в нем есть все поля из таблицы, которые нужны запросу (если чего-то не хватает, то придется идти в таблицу, а это уже не Index-only).
А будет использоваться или нет — это зависит от решения планировщика. Собственно, планировщик поглядит на карту видимости, чтобы скорректировать стоимость в зависимости от того, какой процент страниц сейчас в карте видимости.
Поскольку картинка взята из моей книги, позволю себе ответить.
Стоимость последовательного сканирования — константа, мы просто читаем всю таблицу.
Index-only Scan — в хорошем случае, когда все страницы в карте видимости — читает только индекс. Если индекс меньше таблицы (а обычно так и бывает), то прочитать даже весь индекс целиком будет эффективнее.
Но вот в плохом случае, когда страниц нет в карте видимости, Index-only Scan превращается в тыкву, то есть в обычный Index San. А это уже всяко дороже, чем Seq Scan.
Тут вот какой момент, раз уж речь о технических статьях. Что, если мы хотим сначала показать таблицу и insert-ы, а потом (в отдельных div-ах) показывать всякие запросы к этой таблице, не повторяя каждый раз вставку? Вроде это довольно-таки базовый сценарий для статей.
Нет, параллельно continue() вызывать нельзя, и не очень понятно зачем: если нужно продолжить генерацию с того момента, где она остановилась, надо просто вызвать continue() один раз.
Если я правильно понимаю идею - готовый стендовый тест нагрузочного тестирования ?
Интересно было бы попробовать генератор в таком качестве. Не уверен, насколько создаваемая им нагрузка показательна, но она всяко разнообразнее pgbench-а. Журналирование только надо вернуть, оно убрано для скорости.
К слову,
GROUP BY ALLуже почти с нами. А вот сSELECT * EXCLUDEне все так однозначно.Андрей, иной раз изменения не точечные, а довольно обширные - будет месиво из разных шрифтов, а их и сейчас уже немало. А еще кто-то может пропустить пару версий, как быть ему? В общем, пока лучший вариант - искать по тексту v.18.
Ну понятно.
Было ж уже: 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-й версии, но вообще это в планах, да.