On Sat, Nov 12, 2011 at 5:09 PM, Florian Pflug <f...@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
refactor-portal-start.patch
Description: Binary data
just-one-snapshot.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
