Re: Is NEW.ctid usable as table_tuple_satisfies_snapshot?
От | Tom Lane |
---|---|
Тема | Re: Is NEW.ctid usable as table_tuple_satisfies_snapshot? |
Дата | |
Msg-id | 2002278.1685119751@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Is NEW.ctid usable as table_tuple_satisfies_snapshot? (Kaiting Chen <ktchen14@gmail.com>) |
Ответы |
Re: Is NEW.ctid usable as table_tuple_satisfies_snapshot?
|
Список | pgsql-hackers |
Kaiting Chen <ktchen14@gmail.com> writes: > On Fri, May 26, 2023 at 11:34 AM David G. Johnston < > david.g.johnston@gmail.com> wrote: >> On Fri, May 26, 2023 at 8:04 AM Kaiting Chen <ktchen14@gmail.com> wrote: >>> 2. If I lookup the row by its ctid, will the visibility map be consulted. >> No, but that doesn't seem to be material anyway. Your user-space pl/pgsql >> function shouldn't care about such a purely performance optimization. It'd be a waste of cycles to consult the map in this usage, since the tuple of interest is surely not all-visible and thus the page couldn't be either. > Just to clarify, there's no way for SELECT FROM foo WHERE ctid = NEW.ctid > to return a row that ordinary wouldn't be visible right? There's no magic > going on with the qual on ctid that skips a visibility check right? No, a ctid test isn't magic in that way; nodeTidscan.c applies the same snapshot check as any other relation scan. regards, tom lane
В списке pgsql-hackers по дате отправления: