Re: Avoiding bad prepared-statement plans. - Mailing list pgsql-hackers

From Bart Samwel
Subject Re: Avoiding bad prepared-statement plans.
Date
Msg-id ded01eb21002110409m5b729dffn168061dae0cad213@mail.gmail.com
Whole thread Raw
In response to Re: Avoiding bad prepared-statement plans.  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Avoiding bad prepared-statement plans.
Re: Avoiding bad prepared-statement plans.
List pgsql-hackers
Hi Robert,

On Tue, Feb 9, 2010 at 17:43, Robert Haas <robertmhaas@gmail.com> wrote:
On Tue, Feb 9, 2010 at 7:08 AM, Jeroen Vermeulen <jtv@xs4all.nl> wrote:
> = Projected-cost threshold =
>
> If a prepared statement takes parameters, and the generic plan has a high
> projected cost, re-plan each EXECUTE individually with all its parameter
> values bound.  It may or may not help, but unless the planner is vastly
> over-pessimistic, re-planning isn't going to dominate execution time for
> these cases anyway.

How high is high?

Perhaps this could be based on a (configurable?) ratio of observed planning time and projected execution time. I mean, if planning it the first time took 30 ms and projected execution time is 1 ms, then by all means NEVER re-plan. But if planning the first time took 1 ms and resulted in a projected execution time of 50 ms, then it's relatively cheap to re-plan every time (cost increase per execution is 1/50 = 2%), and the potential gains are much greater (taking a chunk out of 50 ms adds up quickly).

Cheers,
Bart

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Bugs in b-tree dead page removal
Next
From: Boszormenyi Zoltan
Date:
Subject: Re: CommitFest status summary 2010-01-27