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

From Kevin Grittner
Subject Re: why do we need two snapshots per query?
Date
Msg-id 4EBFBB0C0200002500042DD7@gw.wicourts.gov
Whole thread Raw
In response to why do we need two snapshots per query?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
> Tom Lane  wrote:
> Robert Haas  writes:
>> I can understand why you think it's a bad idea to preserve a
>> snapshot across multiple protocol messages (parse/bind/execute),
>> but why or how would it be a bad idea to keep the same snapshot
>> between planning and execution when the whole thing is being done
>> as a unit? You haven't offered any real justification for that
>> position,
>
> It's not hard to come by: execution should proceed with the latest
> available view of the database.
I don't think that stands as an intuitively obvious assertion.  I
think we need to see the argument which leads to that conclusion.
>> and it seems to me that if anything the semantics of such a thing
>> are far *less* intuitive than it would be to do the whole thing
>> under a single snapshot.
>
> In that case you must be of the opinion that extended query
> protocol is a bad idea and we should get rid of it, and the same
> for prepared plans of all types. What you're basically proposing is
> that simple query mode will act differently from other ways of
> submitting a query, and I don't think that's a good idea.
In what way would that difference be user-visible?
> One of the reasons I don't want to go this direction is that it
> would re-introduce causes of extended query protocol having poor
> performance relative to simple protocol. That's not something that
> users find intuitive or desirable, either.
If the simple protocol can perform better than the extended protocol,
it hardly seems like a good idea to intentionally cripple the fast
one to keep them at the same performance.  It seems like it would be
better to document the performance difference so that people can
weigh the trade-offs.
-Kevin


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: BuildFarm - Jaguar Check Failure
Next
From: Tom Lane
Date:
Subject: Poor use of caching in rangetypes code