Skip site navigation (1) Skip section navigation (2)

Re: Poor plan choice in prepared statement

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 (view raw or flat)
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

In response to

pgsql-performance by date

Next:From: Guillaume SmetDate: 2009-01-01 18:22:56
Subject: Re: Poor plan choice in prepared statement
Previous:From: Alvaro HerreraDate: 2008-12-31 16:01:18
Subject: Re: Poor plan choice in prepared statement

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group