Horton
Menu

Re: Avoiding bad prepared-statement plans.

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: Robert Haas <robertmhaas@gmail.com>
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-02T23:54:28Z
Lists: pgsql-hackers 
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.  :-(

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  PG East:  http://www.enterprisedb.com/community/nav-pg-east-2010.do