Hi, On 2023-03-21 21:02:08 +0100, Matthias van de Meent wrote: > On Tue, 21 Mar 2023 at 20:58, Andres Freund <and...@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
