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:40:11
Message-ID: alpine.DEB.1.10.0901011239140.15026@asgard.lang.hm
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Thu, 1 Jan 2009, Guillaume Smet wrote:

> On Thu, Jan 1, 2009 at 9:24 PM, <david(at)lang(dot)hm> wrote:
>> forgive my ignorance here, but if it's unnamed how can you reference it
>> later to take advantage of the parsing?
>
> You can't. That's what unnamed prepared statements are for.
>
> It's not obvious to me that the parsing phase is worth any "caching".
> From my experience, the planning phase takes far much time on complex
> queries.

the poster who started this thread had a query where the parsing phase
took significantly longer than the planning stage.

David Lang

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Robert Haas 2009-01-06 03:15:29 bad selectivity estimates for CASE
Previous Message david 2009-01-01 20:24:52 Re: Poor plan choice in prepared statement