Re: CommandCounterIncrement versus plan caching
От | Gregory Stark |
---|---|
Тема | Re: CommandCounterIncrement versus plan caching |
Дата | |
Msg-id | 8763zixaxw.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: CommandCounterIncrement versus plan caching (Gregory Stark <stark@enterprisedb.com>) |
Список | pgsql-hackers |
"Gregory Stark" <stark@enterprisedb.com> writes: > "Tom Lane" <tgl@sss.pgh.pa.us> writes: > >> I think this can be fixed by changing the Executor so that it doesn't >> use snapshot->curcid for this purpose. Instead, add a field to EState >> showing the CommandID to mark tuples with. ExecutorStart, which has >> enough information to know whether the query is read-only or not, >> can set this field, or not, and tell GetCurrentCommandId to mark the >> command ID "dirty" (or not). > > ExecutorStart could also determine when the query is a "write-only" query for > which the provided command id won't be used for any snapshot checks (ie, a > simple INSERT) and tell CCI not to bump the CCI if the previous CC even if > it's dirty. oops, garbled that. "tell CCI not to bump the counter even if it's dirty"q -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB'sPostgreSQL training!
В списке pgsql-hackers по дате отправления: