Re: Recovering from detoast-related catcache invalidations

Поиск
Список
Период
Сортировка
От Xiaoran Wang
Тема Re: Recovering from detoast-related catcache invalidations
Дата
Msg-id CAGjhLkMzm=+z=VJedZ5Zi2FFDjj+nXqx4cKfTOryZ+tQYpL8jw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Recovering from detoast-related catcache invalidations  (Xiaoran Wang <fanfuxiaoran@gmail.com>)
Ответы Re: Recovering from detoast-related catcache invalidations  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hmm, how about first checking if any invalidated shared messages have been accepted, then rechecking the tuple's visibility?
If there is no invalidated shared message accepted during 'toast_flatten_tuple', there is no need to do then visibility check, then it can save several
CPU cycles.

----
   if (inval_count != SharedInvalidMessageCounter && !systable_recheck_tuple(scandesc, ntp))
   {
              heap_freetuple(dtp);
              return NULL;
    }
----


Xiaoran Wang <fanfuxiaoran@gmail.com> 于2024年1月13日周六 13:16写道:
Great! That's what exactly we need.

The patch LGTM,  +1


Tom Lane <tgl@sss.pgh.pa.us> 于2024年1月13日周六 04:47写道:
I wrote:
> This is uncomfortably much in bed with the tuple table slot code,
> perhaps, but I don't see a way to do it more cleanly unless we want
> to add some new provisions to that API.  Andres, do you have any
> thoughts about that?

Oh!  After nosing around a bit more I remembered systable_recheck_tuple,
which is meant for exactly this purpose.  So v4 attached.

                        regards, tom lane

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Banck
Дата:
Сообщение: Re: [PATCH] New predefined role pg_manage_extensions
Следующее
От: Andrei Lepikhov
Дата:
Сообщение: Re: POC: GROUP BY optimization