Re: Prepared statements considered harmful

From: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, Gregory Stark <gsstark(at)mit(dot)edu>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Prepared statements considered harmful
Date: 2006-09-02 22:40:38
Message-ID: 20060902224038.GM84229@nasby.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 01, 2006 at 10:18:37AM -0400, Tom Lane wrote:
> Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> >> The server has to prepare the query sometime. The v3 protocol just gives you
> >> control over when that happens, but it doesn't force you to do it at any
> >> particular time.
>
> > Not really. All named prepares are planned straight away, all unnamed
> > ones are planned at bind time. Therefore you cannot have more than one
> > parsed-but-not-planned prepared query at a time. In a connection pool
> > scenario there's no way to share such plans since you can't tell which
> > query has been prepared. That's not forcing, but it's an asymmetry we
> > could do with out.
>
> Sure, but how much does it really matter? If you don't want the plan
> saved for reuse, merely avoiding retransmission of the query text does
> not seem like a major win. Having had time to think about it, I no
> longer think the protocol design is a blocking bug for this problem
> area. It's something we could improve when we are ready to design
> protocol V4, but it does not seem in itself enough reason to make a
> new protocol (with all the pain that entails).

That should either go into the TODO, or a "V4 wishlist"...
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2006-09-02 22:41:55 Re: gBorg status?
Previous Message Bruce Momjian 2006-09-02 22:23:28 Re: Coding style for emacs