Re: On the need for a snapshot in exec_bind_message()

On 2018-09-05 18:45:52 -0400, Tom Lane wrote:
> Daniel Wood <hexexpert(at)comcast(dot)net> writes:
> >>> exec_bind_message()
> >>> PushActiveSnapshot(GetTransactionSnapshot());
> >>>
> >>> If there were no input functions, that needed this, nor reparsing or
> >>> reanalyzing needed, and we knew this up front, it'd be a huge win.
>
> >> Unfortunately, that's not the case, so I think trying to get rid of
> >> this call is a nonstarter.
>
> > Queries stop getting re-optimized after 5 times, unless better plans are to be had. In the absence of schema changes or changing search path why is the snapshot needed?
>
> 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?

> You could maybe argue that immutable input functions shouldn't need
> snapshots, but there are enough not-immutable ones that I don't think
> that gets you very far. In any case, we'd still need a snapshot for
> query execution. The set of queries that could possibly never need
> a snapshot at all is probably not large enough to be interesting.

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.

Greetings,

Andres Freund