Re: Avoiding bad prepared-statement plans.
Bart Samwel <bart@samwel.tk>
From: Bart Samwel <bart@samwel.tk>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jeroen Vermeulen <jtv@xs4all.nl>, pgsql-hackers@postgresql.org
Date: 2010-02-11T12:09:33Z
Lists: 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