PostgreSQL
 sql >> Base de données >  >> RDS >> PostgreSQL

Postgresql - La requête s'exécute beaucoup plus rapidement avec enable_nestloop=false. Pourquoi le planificateur ne fait-il pas ce qu'il faut?

Si le planificateur de requêtes choisit des plans de requête sous-optimaux, il est probable qu'il dispose d'informations incomplètes ou trompeuses sur lesquelles travailler.

Voir cette page Wiki PostgreSQL sur le réglage du serveur. Faites particulièrement attention aux chapitres sur random_page_cost et default_statistics_target .
Lire également les chapitres correspondants dans le manuel sur Statistiques Utilisé par le planificateur et Constantes de coût du planificateur .

Plus précisément, cela pourrait aider à augmenter l'statistics target pour les colonnes suivantes :

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;

Ceux-ci sont impliqués dans les filtres résultant de la

Il y en a plus . Vérifiez chaque colonne où la raboteuse s'écarte beaucoup de l'estimation. La valeur par défaut est juste 100. N'a de sens que pour les tables avec>> 1000 lignes. Expérimentez avec le réglage. Exécutez ANALYZE sur les tables par la suite pour que les modifications prennent effet.

Il peut également être utile de créer un index partiel sur postgres(sales_orders.retailer_id) WHERE retailer_id IS NOT NULL (selon la fréquence des valeurs NULL).

Une autre chose qui peut vous aider est de mettre à jour à la dernière version 9.1. Il y a eu un certain nombre d'améliorations substantielles dans ce domaine.