Re: Avoiding bad prepared-statement plans.

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Mark Mielke <mark(at)mark(dot)mielke(dot)cc>, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeroen Vermeulen <jtv(at)xs4all(dot)nl>, Greg Stark <gsstark(at)mit(dot)edu>, Bart Samwel <bart(at)samwel(dot)tk>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Avoiding bad prepared-statement plans.
Date: 2010-03-02 23:54:28
Message-ID: 201003022354.o22NsSM14130@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2010-03-03 00:22:00 Re: Hot Standby query cancellation and Streaming Replication integration
Previous Message Bruce Momjian 2010-03-02 23:53:56 Re: Avoiding bad prepared-statement plans.