| From: | "Robert Haas" <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | "Alvaro Herrera" <alvherre(at)commandprompt(dot)com> |
| Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Scott Carey" <scott(at)richrelevance(dot)com>, bricklen <bricklen(at)gmail(dot)com>, "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>, "Merlin Moncure" <mmoncure(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Poor plan choice in prepared statement |
| Date: | 2009-01-01 13:44:50 |
| Message-ID: | 603c8f070901010544p53f01ae0x4920c6edf4c57a2c@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Wed, Dec 31, 2008 at 11:01 AM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
>> The point of a prepared statement IMHO is to do the planning only once.
>> There's necessarily a tradeoff between that and having a plan that's
>> perfectly adapted to specific parameter values.
>
> I think it has been shown enough times that the performance drop caused
> by a worse plan can be orders of magnitudes worse than what's gained by
> producing the plan only once. It does not seem a bad idea to provide a
> way to carry out only the parse phase, and postpone planning until the
> parameters have been received.
+1.
...Robert
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Guillaume Smet | 2009-01-01 18:22:56 | Re: Poor plan choice in prepared statement |
| Previous Message | Alvaro Herrera | 2008-12-31 16:01:18 | Re: Poor plan choice in prepared statement |