Re: Avoiding bad prepared-statement plans.
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Mark Mielke <mark@mark.mielke.cc>, Jeroen Vermeulen <jtv@xs4all.nl>, Alex Hunsaker <badalex@gmail.com>, Greg Stark <gsstark@mit.edu>, Bart Samwel <bart@samwel.tk>, Pavel Stehule <pavel.stehule@gmail.com>, pgsql-hackers@postgresql.org
Date: 2010-03-01T02:47:38Z
Lists: pgsql-hackers
On Sat, Feb 27, 2010 at 11:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Fri, Feb 26, 2010 at 7:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Wouldn't it be better if it just did the right thing automatically? >>> >>> The sort of heuristic I'm envisioning would essentially do "replan every >>> time" for some number of executions, and give up only if it noticed that >>> it wasn't getting anything better than the generic plan. So you'd have >>> a fixed maximum overhead per session when the custom plan was useless, >>> and the Right Thing when it wasn't. > >> Which is likely useless for my use case. > > [ shrug... ] You'd better explain exactly why, if you want me to take > that objection seriously. Hmm... on further thought, maybe it *would* work in that case. I'm still not convinced this is going to be generally satisfactory. It seems like it depends a great deal on how many times the function figures to be called per session and in what percentage of those cases a non-generic plan figures to be better. The appeal of a user-controllable knob is that I am pretty sure from experience that I can set it correctly, but hey... ...Robert