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
|
| Список | 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;
}
{
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, +1Tom 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 по дате отправления: