Postgresql - Заявката работи много по-бързо с enable_nestloop=false. Защо проектантът не прави правилното нещо?

Ако инструментът за планиране на заявки избере неоптимални планове за заявки, има вероятност той да има непълна или подвеждаща информация, с която да работи.

Вижте тази страница на PostgreSQL Wiki при настройка на сървъра. Обърнете специално внимание на главите за random_page_cost и default_statistics_target .
Прочетете също съответните глави в ръководството за Статистика Използва се от Planner и Константи на разходите на Planner .

По-конкретно, може да помогне за увеличаване на statistics target за следните колони:

ALTER TABLE postgres.products ALTER COLUMN id SET STATISTICS 1000;
ALTER TABLE postgres.sales_orders ALTER COLUMN retailer_id SET STATISTICS 1000;
ALTER TABLE postgres.sales_orders ALTER COLUMN company_id SET STATISTICS 1000;

ALTER TABLE goods_return_notes ALTER COLUMN retailer_id SET STATISTICS 1000;
ALTER TABLE goods_return_notes ALTER COLUMN company_id SET STATISTICS 1000;

ALTER TABLE retailer_category_leaf_nodes ALTER COLUMN tree_left SET STATISTICS 1000;
ALTER TABLE channels ALTER COLUMN principal_id SET STATISTICS 1000;

Те участват във филтрите, водещи до

Има още . Проверете всяка колона, където рендето се отклонява много от оценката. По подразбиране е само 100. Има смисъл само за таблици с>> 1000 реда. Експериментирайте с настройката. Стартирайте ANALYZE на масите след това, за да влязат в сила промените.

Може също да помогне да създадете частичен индекс на postgres(sales_orders.retailer_id) WHERE retailer_id IS NOT NULL (в зависимост от това колко често срещани са стойностите NULL).

Друго нещо, което може да ви помогне, е да надстроите до най-новата версия 9.1. Има редица съществени подобрения в тази област.