Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Sur une version 9.5 (!!!) en Azure for postgresql single server, j'ai une requête qui met environ 4H à s'exécuter. Il y a une grosse table de presque 200 millions de lignes d'un côté et une autre de quelques centaines de milliers.
Dans le plan d'exécution https://explain.dalibo.com/plan/vmJ, j'ai une branche avec un SORT de 6096 lignes (actual) suivi ensuite d'un materialize qui a 25 milliards en rows.
Ensuite entre le materialize et l'autre branche, j'ai un merge left join qui met 4H à s'exécuter et passe tout son temps à retirer les 25 milliards de lignes.
En testant sur une v11 (Azure for postgresql single server), je n'ai plus le materialize sur un volume similaire, j'ai le sort et tout de suite le merge left join. Et la requête tourne en une dizaine de min. J'ai aussi du parallelisme sur le merge que je n'ai pas en 9.5 (la doc sur parallel plans ne me donne pas de lien 9.5) et je n'ai jamais travaillé sur cette version, est-ce que ça signifie qu'elle ne fait pas de parallelism ou de façon très limitée ?
Je suppose que le plannificateur a ce comportement particulier de materialize en 9.5 et pas en 11.
Comment est-ce que ce 25 milliards est calculé ? Est-ce juste le plannificateur qui fonctionne comme cela pour l'époque ?
Est-ce qu'il y aurait, juste pour ma culture personnelle, une astuce qui permet de supprimer ce materialize (il est prévu de migrer en v11 pour ne pas rester sur une version non supportée - et je pense que ça réglera ce soucis et il suffira d'optimiser ensuite de manière classique) ?
Merci.
Hors ligne
Les 25 milliards, c'est les "25 milliards d'enregistrements que le nœud a produits", dont la plupart sont ensuite supprimés par le join filter. J'imagine que c'est parce qu'il est obligé de produire ses enregistrements plusieurs fois pour le merge join, si on a n-n id_marque qui correspondent . Pour supprimer le materialize, tu peux essayer de désactiver enable_materialize juste avant d'exécuter cette requête. J'ai déjà eu des environnements où désactiver materialize sur des requêtes apportait de meilleurs résultats... maintenant que j'y repense, la dernière fois, ça devait être une 9.6 
Dernière modification par Marc Cousin (06/04/2022 11:09:20)
Marc.
Hors ligne
J'ai aussi du parallelisme sur le merge que je n'ai pas en 9.5 (la doc sur parallel plans ne me donne pas de lien 9.5) et je n'ai jamais travaillé sur cette version, est-ce que ça signifie qu'elle ne fait pas de parallelism ou de façon très limitée ?
Oui, le parallélisme intra-requête est apparu avec la version 9.6.
https://www.postgresql.org/docs/9.6/parallel-query.html
Sinon la version 11 date de 2018 et sera obsolète en 2023, il serait préférable de migrer sur la dernière version qui est la 14.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Merci. Je vais essayer de le faire (il faut que je planifie avec le métier).
Hors ligne
Bon, ça a tourné pendant des heures sans aboutir et fait planter mon client.
Mais au moins, le métier est d'accord pour migrer sur au moins une v11 (v13 possible si je peux aller sur du Azure PostgreSQL flexible server).
Hors ligne
Pages : 1
