Re: PG15 beta1 sort performance regression due to Generation context change - Mailing list pgsql-hackers

From David Rowley
Subject Re: PG15 beta1 sort performance regression due to Generation context change
Date
Msg-id CAApHDvoEC1=9kp8_f6B9rMySnxwjftJzQLWb_ss-=vj+Q6dZ3g@mail.gmail.com
Whole thread Raw
In response to Re: PG15 beta1 sort performance regression due to Generation context change  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PG15 beta1 sort performance regression due to Generation context change
List pgsql-hackers
On Tue, 24 May 2022 at 09:36, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> However, here's a different idea: how badly do we need the "size"
> field in GenerationChunk?  We're not going to ever recycle the
> chunk, IIUC, so it doesn't matter exactly how big it is.  When
> doing MEMORY_CONTEXT_CHECKING we'll still want requested_size,
> but that's not relevant to performance-critical cases.

Interesting idea. However, I do see a couple of usages of the "size"
field away from MEMORY_CONTEXT_CHECKING builds:

GenerationRealloc: uses "size" to figure out if the new size is
smaller than the old size.  Maybe we could just always move to a new
chunk regardless of if the new size is smaller or larger than the old
size.

GenerationGetChunkSpace: Uses "size" to figure out the amount of
memory is used by the chunk. I'm not sure how we'd work around the
fact that USEMEM() uses that extensively in tuplesort.c to figure out
how much memory we're using.

David



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: allow building trusted languages without the untrusted versions
Next
From: Ranier Vilela
Date:
Subject: Re: PG15 beta1 sort performance regression due to Generation context change