Hi, On 2023-02-08 09:57:04 -0500, Tom Lane wrote: > Tomas Vondra <tomas.von...@enterprisedb.com> writes: > > Note: To be precise this is not about "executions" but about snapshots, > > and we could probably simplify the function call with isolation levels > > that maintain a single snapshot (e.g. REPEATABLE READ). But we don't. > > We don't do that because, in fact, execution is *never* done with the same > snapshot used for planning. See comment in postgres.c: > > * While it looks promising to reuse the same snapshot for query > * execution (at least for simple protocol), unfortunately it causes > * execution to use a snapshot that has been acquired before locking > * any of the tables mentioned in the query. This creates user- > * visible anomalies, so refrain. Refer to > * https://postgr.es/m/flat/5075d8df.6050...@fuzzy.cz for details. > > I'm not entirely sure that that locking argument still holds, but having > been burned once I'm pretty hesitant to try that again.
Because we now avoid re-computing snapshots, if there weren't any concurrent commits/aborts, the gain would likely not be all that high anyway. We should work on gettting rid of the ProcArrayLock acquisition in case we can reuse the snapshot, though. I think it's doable safely, but when working on it, I didn't succeed at writing a concise description as to why it's sfae, so I decided that the rest of the wins are big enough to not focus on it then and there. Greetings, Andres Freund