Re: why do we need two snapshots per query? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: why do we need two snapshots per query?
Date
Msg-id CA+TgmoaOgJ_9OpKWx01jiG7ZDvf3xCpAkYTJdV-5uWkS4rSQdw@mail.gmail.com
Whole thread Raw
In response to Re: why do we need two snapshots per query?  (Florian Pflug <fgp@phlo.org>)
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Thom Brown
Date:
Subject: Re: FDW system columns
Next
From: Andrew Dunstan
Date:
Subject: Re: pg_restore --no-post-data and --post-data-only