Re: why do we need two snapshots per query?

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, Nov 13, 2011 at 11:09 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I remain of the opinion that Robert's proposal is a bad idea.

> Wait a minute. 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.

> 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. It might be sane if planning
could be assumed to take zero time, but that's hardly true.

> I also think you are dismissing Simon's stable-expression-folding
> proposal far too lightly. I am not sure that the behavior he wants is
> safe given the current details of our implementation - or even with my
> patch; I suspect a little more than that is needed - but I am pretty
> certain it's the behavior that users want and expect, and we should be
> moving toward it, not away from it. I have seen a significant number
> of cases over the years where the query optimizer generated a bad plan
> because it did less constant-folding than the user expected.

This is just FUD, unless you can point to specific examples where
Marti's patch won't fix it. If that patch crashes and burns for
some reason, then we should revisit this idea; but if it succeeds
it will cover more cases than plan-time constant folding could.

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.

regards, tom lane