On 2018-09-05 18:45:52 -0400, Tom Lane wrote: > Daniel Wood <hexexp...@comcast.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
