Re: En

From: Xavier Poinsard <xpoinsard(at)free(dot)fr>
To: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: En
Date: 2005-09-13 13:48:13
Message-ID: 4326D89D.3070206@free.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-fr-generale

Sébastien Dinot a écrit :
> Xavier Poinsard a écrit :
> | Utilises-tu (directement ou indirectement) des "Prepared statements" ?
>
> Oui, en effet, j'en utilise systématiquement car ils sont connus pour
> améliorer les performances.
>
> | Car dans ce cas l'explication est simple. Lors du premier insert
> | dans la table vide, Postgresql choisit un plan d'exécution basé sur
> | le fait que la table est vide. Ensuite toutes les insertions
> | utilisent le même plan, sauf si tu recrées complement le "Prepared
> | statement" (et si ton pool de connection ne le cache pas).
>
> Autrement dit, il faut que je détruise et régénère mes requêtes
> préparées à la fin de chaque boucle. Outchh...

Pas forcément, il faut peut-être simplement éviter de mettre à jour les
statistiques avec ANALYZE lorsque la table est vide ou recréer une fois
les Prepared statements lorsque la table a atteint un certain remplissage.

>
> | Par contre lors de la deuxième exécution, le plan est calculé sur un
> | table pleine et donc Postgresql choisit le bon plan.
>
> Ne connaissant pas le mode de fonctionnement des requêtes préparées,
> je me contentais d'en mettre partout sans me poser plus de questions
> mais à la lumière de tes explications, tout devient limpide et
> évident !
>
> Je viens de jeter un oeil à la doc de PostgreSQL (sql-prepare.html) et
> il y est dit ceci :
>
> « In some situations, the query plan produced by for a prepared
> statement may be inferior to the plan produced if the statement were
> submitted and executed normally. This is because when the statement
> is planned and the planner attempts to determine the optimal query
> plan, the actual values of any parameters specified in the statement
> are unavailable. PostgreSQL collects statistics on the distribution
> of data in the table, and can use constant values in a statement to
> make guesses about the likely result of executing the statement.
> Since this data is unavailable when planning prepared statements
> with parameters, the chosen plan may be suboptimal. To examine the
> query plan PostgreSQL has chosen for a prepared statement, use
> EXPLAIN EXECUTE. »
>
> Merci beaucoup pour ce précieux tuyau. Je modifie sur le champ mon
> code et je reviens vous dire ce qu'il en est dès que j'ai un résultat.
>
> Sébastien
>

In response to

  • Re: En at 2005-09-13 13:11:07 from Sébastien Dinot

Responses

  • Re: En at 2005-09-16 09:14:12 from Sébastien Dinot

Browse pgsql-fr-generale by date

  From Date Subject
Next Message CHARABOUSKA Christel 2005-09-13 14:28:38 Configuration postgresql
Previous Message Sébastien Dinot 2005-09-13 13:11:07 Re: En