Re: lsyscache: free IndexAmRoutine objects returned by GetIndexAmRoutineByAmId()

Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> writes:
> On Mon, 29 Dec 2025 at 17:05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I wonder if it wouldn't be better to rethink the convention that
>> IndexAmRoutine structs are palloc'd. Is there any AM for which
>> the contents aren't constant, so that we could just return a pointer
>> to a static constant struct and save the palloc/pfree overhead?

> I'm not aware of any such AMs, and the only reason I can think of to
> change this dynamically is for specialization: the amroutine itself
> doesn't get sufficient information to return a specialized
> IndexAmRoutine pointer; and assuming that rd_indam itself isn't
> `const`-ified the specializing code would just have to change the
> pointed-to IndexAmRoutine instead of replacing individual am*
> functions in the struct.

Yeah, it's hard to credit any need for per-call specialization
given that the amhandler receives no parameters. I can imagine
per-session specialization, for instance as a result of wanting
to JIT-compile the AM's methods. But you could still do that:
on first call, build one copy of the IndexAMRoutine struct in
a long-lived context, and then just keep returning pointers to
that struct. The "const" requirement applies to the core code's
references to the IndexAMRoutine struct, it does not constrain
the code creating such a struct.

> Here's my patch that does this, pulled from [0]. It was originally
> built to reduce the per-index catcache overhead; as using static const
> pointers reduces the data allocated into the "index info" context by
> 264 bytes.

Cool, I forgot you'd already been poking at this. The patch
is kinda long, but not as bad as I feared, and it all looks
quite mechanical. It lacks documentation updates though.

regards, tom lane