Re: Reducing the chunk header sizes on all memory context types - Mailing list pgsql-hackers

From David Rowley
Subject Re: Reducing the chunk header sizes on all memory context types
Date
Msg-id CAApHDvptxH8W+JVyQuASm8n9RTpA_tdiHZCi0SgYKzFcnionTQ@mail.gmail.com
Whole thread Raw
In response to Re: Reducing the chunk header sizes on all memory context types  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Reducing the chunk header sizes on all memory context types
List pgsql-hackers
On Thu, 8 Sept 2022 at 03:08, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 4. For aset.c, I'd be inclined to have it compute the AllocBlock
> address implied by the putative chunk header, and then run through
> the context's alloc blocks and see if any of them match.  If we
> do find a match, and the chunk address is within the allocated
> length of the block, call it good.  Probably the same could be done
> for the other two methods.
>
> Step 4 is annoyingly expensive, but perhaps not too awful given
> the way we step up alloc block sizes.  We should make sure that
> any context we want to use MemoryContextContains with is allowed
> to let its blocks grow large, so that there can't be too many
> of them.

Thanks for the idea. I've not come up with anything better other than
remove the calls to MemoryContextContains and just copy the Datum each
time.  That doesn't fix the problems with function, however.

I'll go code up your idea and see if doing that triggers any other ideas.

David



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: predefined role(s) for VACUUM and ANALYZE
Next
From: Jacob Champion
Date:
Subject: Re: pg_upgrade failing for 200+ million Large Objects