From: | Xiaoran Wang <fanfuxiaoran(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: Recovering from detoast-related catcache invalidations |
Date: | 2024-01-13 09:02:15 |
Message-ID: | CAGjhLkMzm=+z=VJedZ5Zi2FFDjj+nXqx4cKfTOryZ+tQYpL8jw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)gmail(dot)com> 于2024年1月13日周六 13:16写道:
> Great! That's what exactly we need.
>
> The patch LGTM, +1
>
>
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
>>
>>
From | Date | Subject | |
---|---|---|---|
Next Message | Andrei Lepikhov | 2024-01-13 09:08:59 | Re: POC: GROUP BY optimization |
Previous Message | Michael Banck | 2024-01-13 08:20:40 | Re: [PATCH] New predefined role pg_manage_extensions |