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 по дате отправления: