Re: Make tuple deformation faster

On Wed, 4 Dec 2024 at 23:52, David Rowley <dgrowleyml@gmail.com> wrote:
>
> On Thu, 5 Dec 2024 at 03:51, Andres Freund <andres@anarazel.de> wrote:
> > Possibly stupid idea: Could we instead store the attributes *before* the main
> > TupleDescData, with increasing "distance" for increased attnos?  That way we
> > wouldn't need to calculate any variable offsets. Of course the price would be
> > to have some slightly more complicated invocation of pfree(), but that's
> > comparatively rare.
>
> Are you thinking this to make the address calculation cheaper? or so
> that the hacky code that truncates the TupleDesc would work without
> crashing still?
>
> If it's for the latter then the pfree() would be tricky to make work
> still as natts would need to be consulted to find the address to
> pfree.

It's certainly tricky (I'd say quite a hack, even), but you could put
a MCTX_ALIGNED_REDIRECT_ID -type memory chunk ahead of the main
TupleDescData, and put any other data you want ahead of that redirect
chunk (so you'd have the normal palloc() MemoryChunk header (at
allocptr - sizeof(MemoryChunk), followed by variable data, followed by
the redirect MemoryChunk, followed by the to-be-returned TupleDesc's
data). This ALIGNED_REDIRECT MemoryChunk will safely forward calls to
pfree on the TupleDesc pointer to the base pointer of the palloc()-ed
area, which then is forwarded to the actual memory context.

That said, I don't think it'd be safe to use with repalloc, as that
would likely truncate the artificial hole in the memory chunk,
probably requiring restoration work by the callee on the prefixed
arrays. That may be a limitation we can live with, but I haven't
checked to see if there are any usages of repalloc() on TupleDesc.

Kind regards,

Matthias van de Meent
Neon (https://neon.tech)