On Sat, Nov 12, 2011 at 5:09 PM, Florian Pflug <fgp@phlo.org> wrote:
> On Nov11, 2011, at 19:17 , Tom Lane wrote:
>> But frankly I do not like any of these proposals. Making fundamental
>> changes in long-established semantics in the name of squeezing out a few
>> cycles is the wrong way to design software.
>
> Hm, then maybe this is one of the things to put onto the next protocol
> version todo list?
+1. I had the same thought. It seems clear that we could design this
in a way that would make it clear to the server whether we wanted to
execute immediately or only upon further instructions, but trying to
guess the user's intentions seems a little too rich.
Meanwhile, here's my attempt at fixing this for the simple query
protocol. I'm attaching two patches:
- refactor-portal-start.patch, which attempts to change the API for
PortalStart() without any behavioral change whatsoever. The idea here
is that instead of passing a snapshot to PortalStart() explicitly, we
just pass a flag saying whether or not it's OK to use the active
snapshot (versus taking a new one). This seems to fit nicely with
existing calling patterns for this function.
- just-one-snapshot.patch, which applies atop
refactor-portal-start.patch, makes use of the new API to avoid the
need for PORTAL_ONE_SELECT queries to take two snapshots. It does so
by keeping the parse/analyze snapshot around just long enough to pass
it to PortalStart(). If PortalStart() chooses to register it, then it
(or a copy of it) will be around for a while longer; otherwise, it
will be dropped immediately after PortalStart() finishes.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company