Vous n'êtes pas identifié(e).
Pages : 1
Bonjour a tous,
le fait d’exécuter une requête avec ses paramètres directement ou via une PreparedStatement donc avec des ? temporaire a la places des paramètres finaux, a t'il une incidence sur le choix du plan d'execution fait par postgres ?
car dans mon cas, j'ai une requête sur une table donnée qui prend 6s quand je la joue dans PGAdmin aprés avoir customisé certaines paramétres : random_page_cost, enable_nestloop = off;
Mais quand elle est lancée directement depuis mon programme par une librairie tierce et donc avec une PreparedStatement, elle prend un temps infini, malgré un paramètrage de postgresql.conf identique.
Merci par avance pour vos idées 
Dernière modification par Sidart (25/06/2012 14:20:59)
Hors ligne
Oui, le plan est très différent: dans la requête préparée, PostgreSQL calcule un plan générique, sans prendre en compte les paramètres. Le plan est donc moins bon, mais calculé une seule fois (si vous maintenez la requête préparée entre deux appels). Ça va un peu changer en 9.2 (il calculera un plan complet un certain nombre de fois, puis basculera sur le plan générique si il constate que celui-ci n'aurait pas été plus de 10% plus coûteux que le plan complet).
Pour cette requête, exécutez la en forçant la planification à chaque fois. Le client est en quel langage ?
Marc.
Hors ligne
Merci a vous pour cette réponse rapide.
Je peut donc forcer le plan précis ?
Mon client est en java. Je travaille sur des volumes de données conséquents, des sélections de millions de lignes parmi des dizaines de millions, donc la perte de temps de calcul du plan elle est vraiment minime. Les requets sont rarement relancée a l'identique.
Hors ligne
Non, vous ne pouvez pas indiquer un plan d'exécution. Simplement ne passez pas par des requêtes préparées.
Guillaume.
Hors ligne
En fait, si, avec java et le driver jdbc on peut.
http://jdbc.postgresql.org/documentatio … epare.html => On peut modifier le preparethreshold. Par défaut, un preparedstatement java n'est vraiment préparé qu'à sa 5e exécution. On peut lui demander de le faire immédiatement (1) ou pas du tout (0), le 0 n'étant d'ailleurs pas dans la doc à ma connaissance.
Par ailleurs, le driver jdbc utilise des curseurs pour tous les ordres. Vous avez donc intérêt, si vous avez besoin qu'il vous choisisse le bon plan, à passer cursor_tuple_fraction à 1 (au lieu de 0.1, qui veut dire «optimise l'ordre en partant de l'hypothèse que le curseur ne va ramener que 10% des enregistrements).
Marc.
Hors ligne
Pages : 1
