Hi,
On 2021-08-19 14:47:42 +0200, Matthias van de Meent wrote:
> I tried to implement this 'compact attribute access descriptor' a few
> months ago in my effort to improve btree index performance.
cool
> The patch allocates an array of 'TupleAttrAlignData'-structs at the
> end of the attrs-array, fills it with the correct data upon
> TupleDesc-creation, and uses this TupleAttrAlign-data for constructing
> and destructing tuples.
> One main difference from what you described was that I used a union
> for storing attbyval and attstorage, as the latter is only applicable
> to attlen < 0, and the first only for attlen >= 0. This keeps the
> whole structure in 8 bytes, whilst also being useable in both tuple
> forming and deforming.
That's why I just talked about the naive way - it's clearly possible to
do better... ;)
> I hope this can is useful, otherwise sorry for the noise.
It is!
I haven't looked at your patch in detail, but I suspect that one reason
that you didn't see performance benefits is that you added overhead as
well. The computation of the "compact" memory location now will need a
few more instructions than before, and I suspect the compiler may not
even be able to optimize out some of the redundant accesses in loops.
It'd be interesting to see what you'd get if you stored the compact
array as the flexible-array and stored a pointer to the "full" attrs
array (while still keeping it allocated together).
Another reason is that it looks like you didn't touch
slot_deform_heap_tuple(), which is I think the hottest of the deforming
routines...
Greetings,
Andres Freund
