Re: Avoiding bad prepared-statement plans.
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Mark Mielke <mark@mark.mielke.cc>, Craig Ringer <craig@postnewspapers.com.au>, Tom Lane <tgl@sss.pgh.pa.us>, Jeroen Vermeulen <jtv@xs4all.nl>, Greg Stark <gsstark@mit.edu>, Bart Samwel <bart@samwel.tk>, Pavel Stehule <pavel.stehule@gmail.com>, pgsql-hackers@postgresql.org
Date: 2010-03-03T05:13:46Z
Lists: pgsql-hackers
On Tue, Mar 2, 2010 at 6:54 PM, Bruce Momjian <bruce@momjian.us> wrote: > Robert Haas wrote: >> > Adding SQL to indicate whether it should be re-planned or not is completely >> > unappealing. If I could change the code, today, I'd just turn off or choose >> > not to use PREPARE/EXECUTE. Today, PREPARE/EXECUTE seems like it should >> > always be considered slower unless one can prove it is actually faster in a >> > specific case, which is the exact opposite of what people expect. >> >> I don't really understand most of what you're saying here, but there's >> definitely some truth to your last sentence. This has easily got to >> be one of the top ten questions on -performance. > > It seems it is the problem everyone knows about but no one fixes. :-( I'd work on it, but Tom doesn't like my proposed fix. *shrug* ...Robert