Можно как то обмануть планировщик запроса, чтоб симулировать ситуацию когда

ну уехавшая стата и нагрузка-таки разные вещи. можно попробовать стейдж при типовой нагрузке придушить по процам и памяти. хз, правда, что это покажет)

0

11 месяцев назад

Yaroslav Schekin

А что Вам мешает (под superuser), если это всё равно тестовый сервер: UPDATE pg_class SET relpages = 200, reltuples = 232132 WHERE relname = 'a table name'; ну и так далее (есть и штатное средство для одной статистики — см. n_distinct в https://www.postgresql.org/docs/current/sql-altertable.html )? Базу поcле таких экспериментов лучше сжечь перезалить, на всякий случай. ;)

0

11 месяцев назад

Aleksandr Danilov 🇺🇦 Автор вопроса

что делают эти параметры?

0

11 месяцев назад

Yaroslav Schekin

Aleksandr Danilov 🇺🇦
что делают эти параметры?

См. https://www.postgresql.org/docs/current/using-explain.html Ну и там ещё описаны статистики, являющиеся фундаментом планирования — всё это можно поменять таким способом, насколько я помню (но вот писать MCV и гистограммы вручную — это морока, конечно... с другой стороны, их можно откуда-то содрать (если есть, откуда... например, если тест — это в 1000 раз уменьшенный (каким-то образом) production, то можно содрать оттуда)).

0

11 месяцев назад

Ilya Portnov · Accepted Answer

pg-шный планировщик ничего не знает про нагрузку (афаик)... т.е. при прочих равных, при большой нагрузке и при малой выберет один и тот же план. а, ну единственное, под нагрузкой у вас visibility maps могут оказаться не обновлены, и вы вместо index-only scan получите index scan. Ну выключите автовакуум временно для эмуляции :)

172 похожих чатов

Можно как то обмануть планировщик запроса, чтоб симулировать ситуацию когда

9 ответов

Похожие вопросы