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

From Tomas Vondra
Subject Re: PG15 beta1 sort performance regression due to Generation context change
Date
Msg-id 5a0ae4e1-d185-bfec-57a4-745536129066@enterprisedb.com
Whole thread Raw
In response to Re: PG15 beta1 sort performance regression due to Generation context change  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: PG15 beta1 sort performance regression due to Generation context change  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: PG15 beta1 sort performance regression due to Generation context change  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
On 5/20/22 12:01, Heikki Linnakangas wrote:
> On 20/05/2022 08:56, David Rowley wrote:
>> The problem is that generation chunks have a larger chunk header than
>> aset do due to having to store the block pointer that the chunk
>> belongs to so that GenerationFree() can increment the nfree chunks in
>> the block. aset.c does not require this as freed chunks just go onto a
>> freelist that's global to the entire context.
> 
> Could the 'context' field be moved from GenerationChunk to GenerationBlock?
> 

Not easily, because GetMemoryChunkContext() expects the context to be
stored right before the chunk. In principle we could add "get context"
callback to MemoryContextMethods, so that different implementations can
override that.

I wonder how expensive the extra redirect would be, but probably not
much because the places touching chunk->context deal with the block too
(e.g. GenerationFree has to tweak block->nfree).


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: allow building trusted languages without the untrusted versions
Next
From: Tom Lane
Date:
Subject: Re: allow building trusted languages without the untrusted versions