Re: Avoiding bad prepared-statement plans.

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bart Samwel <bart(at)samwel(dot)tk>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Jeroen Vermeulen <jtv(at)xs4all(dot)nl>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Avoiding bad prepared-statement plans.
Date: 2010-02-11 13:04:46
Message-ID: 603c8f071002110504yb07519do9dd258c5a0ee6143@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 11, 2010 at 7:48 AM, Bart Samwel <bart(at)samwel(dot)tk> wrote:
> On Thu, Feb 11, 2010 at 13:41, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>
>> On Thu, Feb 11, 2010 at 7:39 AM, Bart Samwel <bart(at)samwel(dot)tk> wrote:
>> > Anyhow, I have no clue how much time the planner takes. Can anybody
>> > provide
>> > any statistics in that regard?
>>
>> It depends a great deal on the query, which is one of the things that
>> makes implementing this rather challenging.
>
> But I guess you can probably expect it to be on the same order for the same
> query in generic form and with filled-in parameters?

I think so.... but I wouldn't bet the farm on it without testing.

> Because that's the
> underlying assumption of the "ratio" criterion -- that re-planning with
> filled-in parameters takes about as much time as the initial planning run
> took.

We only want to replan when replanning is relatively cheap compared to
execution, so the other assumption is that the planning-to-execution
ratio is more or less constant. Whether that's sufficiently true to
make the proposed system useful and reliable is not clear to me.

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2010-02-11 13:06:39 Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Previous Message Robert Haas 2010-02-11 13:01:25 Re: knngist patch support