| From: | "Guillaume Smet" <guillaume(dot)smet(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 18:22:56 |
| Message-ID: | 1d4e0c10901011022v4a1d5eeaidc2692a7729e79df@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Wed, Dec 31, 2008 at 5:01 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> 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.
It's already done in 8.3 for unnamed plans, isn't it?
--
Guillaume
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Guillaume Smet | 2009-01-01 19:29:43 | Re: Poor plan choice in prepared statement |
| Previous Message | Robert Haas | 2009-01-01 13:44:50 | Re: Poor plan choice in prepared statement |