Problème de Performances entre bases avec une même requête

[olivier_44]

Bonjour,

J'ai un gros problème de performances qui m'interpelle.

Je dispose d'un serveur postgres sur lequel sont déployés n bases toutes construites à partir d'un même script, ayant donc la même structure, tables, index ...

Je réalise exactement la même requête sur chaque base et j'obtiens des temps de réponse allant de 0,5 s à 45 s!

La base la plus chargée donne le meilleur temps!

Une instruction VACUUM FULL ANALYZE sur les bases n'y change rien.

Si vous avez une idée de ce qui peut expliquer la chose, moi ça me laisse perplexe.
Merci

[estofilo]

Il faut comparer l'EXPLAIN ANALYZE d'une requête rapide et lente suivant la base.

[olivier_44]

Bon bah,

Les plans d'exécution ne sont pas nécessairement les mêmes entre chaque base. Le point consommateur est identifié :

Code :

1
2
3
4
 
Nested Loop (cost=491.48..73612.24 rows=106514 width=28) (actual time=26.384..10912.759 rows=17181 loops=1)
 
    * JOIN Filter: ((("inner".objet)::text ~~ '%test%'::text) OR ("inner".contenu ~~ '%test%'::text) OR (("outer".nom)::text ~~ '%test%'::text) OR (("outer".sousnom)::text ~~ '%test%'::text) OR (("inner".sousnom)::text

Dans le meilleur des cas ce n'est pas une Nested Loop mais un Merge join qui réalise ce groupe de conditions alors sur beaucoup moins de lignes. Voilà pour les différences.
Mais je n'ai pas l'explication de pourquoi de telles différences et comment les réduire ...

Ca reste pour moi un bon schmilblic!

[estofilo]

Voici différentes choses faisables:
- augmenter la précision des statistiques avec ALTER TABLE SET STATISTICS. Par défaut c'est 100 sur 8.4+ et 10 sur versions antérieures.
- augmenter work_mem pour favoriser le choix d'un merge join. il peut être changé n'importe quand y compris juste pour une requête
- changer les constantes de l'optimiseur comme random_page_cost ou cpu_tuple_cost
- mettre enable_nestloop à false ce qui le forcera à choisir autre chose (méthode recommandée quand rien d'autre ne fonctionne).

[olivier_44]

J'ai fait deux manipulations

- augmenter work_mem pour favoriser le choix d'un merge join
- mettre enable_nestloop à false ou off

Résultat : aucun changement et ce qui est surprenant c'est qu'il continue à utiliser des nested loop.

c'en est désespérant ...