Andres Freund <andres@anarazel.de> writes:
> On 2018-09-05 18:45:52 -0400, Tom Lane wrote:
>> The snapshot has little to do with the query plan, usually. It's about
>> what view of the database the executed query will see, and particularly
>> about what view the parameter input functions will see, if they look.
> The snapshot in exec_bind_message() shouldn't be about what the executed
> query sees, no? Sure, we'll evaluate input params and might replan etc,
> but other than that?
As things stand, yeah, it's not used for execution.
> It'd not be insane to rejigger things so there's a version of
> PushActiveSnapshot() doesn't eagerly compute the snapshot, but instead
> does so on first access. Obviously we couldn't use that everywhere, but
> the exec_bind_message() seems like a prime case for it.
I dislike this proposal, because it introduces an element of uncertainty
into when the snapshot is taken. It doesn't seem a lot different from
saying that we'll try to save a gettimeofday call by postponing
calculation of the statement_timestamp until somebody asks for it.
Then it's no longer the statement start time, but some hard-to-define
time within execution.
I think the other idea of trying to keep the bind-time snapshot in use
throughout execution is more worth pursuing. The main problem with it,
now that I think harder, is that we need the execution snapshot to be
taken after we've acquired whatever locks the query needs. But we
actually know the set of required locks, if we have a cached plan
at hand. (It's *possible* that that set would change, if we're forced
to replan, but it's unlikely.) So you could imagine rejiggering things
so that we do the acquire-locks bit before doing parameter input, and
unless the lock list changes, we can keep the parameter-input snapshot
in force throughout execution. Not quite sure how to make that play
with custom plans though.
regards, tom lane