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
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 |