Hi,
On 2023-03-21 21:02:08 +0100, Matthias van de Meent wrote:
> On Tue, 21 Mar 2023 at 20:58, Andres Freund <andres@anarazel.de> wrote:
> > On 2023-03-21 20:20:40 +0100, Matthias van de Meent wrote:
> > > Yes, attcacheoff is a tremendous performance boon in many cases.
> >
> > Which? We don't use fastgetattr() in many places these days. And in some quick
> > measurements it's a wash or small loss when deforming slot tuples, even when
> > the attcacheoff optimization would apply, because the branches for managing it
> > add more overhead than they safe.
>
> My experience with attcacheoff performance is in indexes, specifically
> index_getattr(). Sure, multi-column indexes are uncommon, but the
> difference between have and have-not for cached attribute offsets is
> several %.
I did indeed not think of index_getattr(), just heap related things.
Do you have a good test workload handy - I'm kinda curious to compare the cost
of removing attcacheoff vs the gain of not maintaining it for index workloads.
It looks like many of the index_getattr() cases could be made faster without
attcacheoff. A lot of places seem to loop over all attributes, and the key to
accelerating that is to keep state between the iterations. Attcacheoff is
that, but quite stunted, because it only works if there aren't any NULLs (even
if the NULL is in a later column).
Greetings,
Andres Freund
