Влияет ли мощность компьютера/сервера на executor plan в Postgres?

Question

[Egor Khombak]

Такая ситуация: есть селект запрос, на который составляем план запроса с помощью explain analyze verbose. И выполняя запрос на 2 разных устройствах, получаем различные значения для cost, rows и width:
для первого

"Limit  (cost=476.22..476.24 rows=5 width=40)\n  Output: augmented_report_table.description, (count(*) OVER (?))\n  CTE augmented_report_table\n    ->  Seq Scan on public.nc_objects  (cost=0.00..472.64 rows=73 width=32)\n          Output: nc_objects.description\n          Filter: ((nc_objects.name)::text = 'vni-0/0'::text)\n  ->  Sort  (cost=3.59..3.77 rows=73 width=40)\n        Output: augmented_report_table.description, (count(*) OVER (?))\n        Sort Key: augmented_report_table.description\n        ->  WindowAgg  (cost=0.00..2.37 rows=73 width=40)\n              Output: augmented_report_table.description, count(*) OVER (?)\n              ->  CTE Scan on augmented_report_table  (cost=0.00..1.46 rows=73 width=32)\n                    Output: augmented_report_table.description\n"

Для второго:

"Limit  (cost=485.85..485.86 rows=5 width=40)\n  Output: augmented_report_table.description, (count(*) OVER (?))\n  CTE augmented_report_table\n    ->  Seq Scan on public.nc_objects  (cost=0.00..472.64 rows=269 width=9)\n          Output: nc_objects.description\n          Filter: ((nc_objects.name)::text = 'vni-0/0'::text)\n  ->  Sort  (cost=13.21..13.88 rows=269 width=40)\n        Output: augmented_report_table.description, (count(*) OVER (?))\n        Sort Key: augmented_report_table.description\n        ->  WindowAgg  (cost=0.00..8.74 rows=269 width=40)\n              Output: augmented_report_table.description, count(*) OVER (?)\n              ->  CTE Scan on augmented_report_table  (cost=0.00..5.38 rows=269 width=32)\n                    Output: augmented_report_table.description\n"

Базы данных одинаковые, версия 11-9. Таблицы тоже одинаковые. Базы развернуты в докере. Единственное что отличается - ПК.
Может быть это причиной? Или какие еще варианты есть, почему результат отличается?

Comments

[Василий Банников]

Емнип, в конфиге всякие метрики указываются, и они влияют на запрос.
Конфиг одинаковый?

[Дмитрий]

А кол-во записей в таблицах одинаковое?

[Egor Khombak]

Василий Банников, а подскажите, как достать этот конфиг?

[Василий Банников]

Egor Khombak, postgresql.conf в папке с данными.

[Egor Khombak]

Василий Банников, Да, конфиги абсолютно идентичны. Ну, это и логично, оба поднимаются с одного докер имеджа

Answer 1

[Egor Khombak]

В ообщем, без понятия в чем была причина. В итоге обновил докер до последней версии на обоих устройствах (был 20.10.8, обновил до 20.10.10) и все завелось, результаты совпадают

Comments

[galaxy]

Данные же также заново в обе БД перезалили?
Проблема была (а, может, и осталась) в статистике, просто вы ее сбросили.
Сделайте в одной из БД ANALYZE и сравните результат.

Answer 2

[galaxy]

Не влияет. Cost считается в попугаях, которые рассчитываются через коэффициенты (коэффициенты определяют во сколько раз медленнее или быстрее операция относительно seq_page_cost - доступа к странице при последовательном чтении).
Разница в Row/width говорит почти наверняка о проблемах со статистикой. Сделайте на обеих базах ANALYZE (можно даже VACUUM FULL ANALYZE, если базы использовались для записи).

Comments

[Egor Khombak]

Коэффициенты стандартные на обоих устройствах. А можно подробнее, о каких проблемах со статистикой вы говорите? Что вообще имеется в виду под "проблемы со статистикой"?

[galaxy]

Egor Khombak, статистика планировщика (1, 2), напрямую влияет на оценку селективности выборок и пр. и на выбор того или иного плана запроса. Если статистика плохо соответствует реальному распределению данных в таблице, планировщик будет сильно ошибаться в оценках и , возможно, будет выбирать неоптимальный план.

Обычно обновляется при автоматическом вакууминге. Однако при крупных загрузках данных в БД или ручных манипуляциях рекомендуется вручную запускать ANALYZE.