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

From Tom Lane
Subject Re: PG15 beta1 sort performance regression due to Generation context change
Date
Msg-id 180278.1654009751@sss.pgh.pa.us
Whole thread Raw
In response to Re: PG15 beta1 sort performance regression due to Generation context change  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: PG15 beta1 sort performance regression due to Generation context change  (Robert Haas <robertmhaas@gmail.com>)
Re: PG15 beta1 sort performance regression due to Generation context change  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> I don't want to take the position that we ought necessarily to commit
> your patch, because I don't really have a clear sense of what the wins
> and losses actually are.

Yeah, we don't have any hard data here.  It could be that it's a win to
switch to a rule that chunks must present an offset (instead of a pointer)
back to a block header, which'd then be required to contain a link to the
actual context, meaning that every context has to do something like what
I proposed for generation.c.  But nobody's coded that up let alone done
any testing on it, and I feel like it's too late in the v15 cycle for
changes as invasive as that.  Quite aside from that change in itself,
you wouldn't get any actual space savings in aset.c contexts unless
you did something with the chunk-size field too, and that seems a lot
messier.

Right now my vote would be to leave things as they stand for v15 ---
the performance loss that started this thread occurs in a narrow
enough set of circumstances that I don't feel too much angst about
it being the price of winning in most other circumstances.  We can
investigate these options at leisure for v16 or later.

            regards, tom lane



pgsql-hackers by date:

Previous
From: "Euler Taveira"
Date:
Subject: Re: Ignore heap rewrites for materialized views in logical replication
Next
From: Andrew Dunstan
Date:
Subject: Re: SQL/JSON functions vs. ECPG vs. STRING as a reserved word