Re: Why cann't simplify stable function in planning phase?
От | Tom Lane |
---|---|
Тема | Re: Why cann't simplify stable function in planning phase? |
Дата | |
Msg-id | 3485170.1675868224@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Why cann't simplify stable function in planning phase? (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
Ответы |
Re: Why cann't simplify stable function in planning phase?
|
Список | pgsql-hackers |
Tomas Vondra <tomas.vondra@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.6050500@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. regards, tom lane
В списке pgsql-hackers по дате отправления: