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

Re: Poor plan choice in prepared statement

From: david(at)lang(dot)hm
To: Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, 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 20:24:52
Message-ID: alpine.DEB.1.10.0901011222190.15026@asgard.lang.hm (view raw or flat)
Thread:
Lists: pgsql-performance
On Thu, 1 Jan 2009, Guillaume Smet wrote:

> 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?

forgive my ignorance here, but if it's unnamed how can you reference it 
later to take advantage of the parsing?

I may just be not understanding the terms being used here.

David Lang

In response to

Responses

pgsql-performance by date

Next:From: davidDate: 2009-01-01 20:40:11
Subject: Re: Poor plan choice in prepared statement
Previous:From: Tom LaneDate: 2009-01-01 20:24:12
Subject: Re: Poor plan choice in prepared statement

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