On Tue, 24 May 2022 at 08:52, Tomas Vondra <tomas.von...@enterprisedb.com> wrote: > > On 5/23/22 22:47, Tom Lane wrote: > > How would you know which context type to consult for that? > > > > D'oh! I knew there has to be some flaw in that idea, but I forgot about > this chicken-or-egg issue.
Handy wavy idea: It's probably too complex for now, and it also might be too much overhead, but having GenerationPointerGetChunk() do a binary search on a sorted-by-memory-address array of block pointers might be a fast enough way to find the block that the pointer belongs to. There should be far fewer blocks now since generation.c now grows the block sizes. N in O(log2 N) the search complexity should never be excessively high. However, it would mean a binary search for every pfree, which feels pretty horrible. My feeling is that it seems unlikely that saving 8 bytes by not storing the GenerationBlock would be a net win here. There may be something to claw back as for the tuplesort.c case as I think the heap_free_minimal_tuple() call in writetup_heap() is not needed in many cases as we reset the tuple context directly afterward writing the tuples out. David