Re: Use CompactAttribute more often, when possible - Mailing list pgsql-hackers

From David Rowley
Subject Re: Use CompactAttribute more often, when possible
Date
Msg-id CAApHDvoxgdXqrUAM0vH_UWTyNKXwf1Kv4hss-D_Qu+xjZh3T_Q@mail.gmail.com
Whole thread Raw
In response to Re: Use CompactAttribute more often, when possible  (Chao Li <li.evan.chao@gmail.com>)
List pgsql-hackers
On Mon, 20 Oct 2025 at 22:33, Chao Li <li.evan.chao@gmail.com> wrote:
> I have removed those ones that you don’t want in v2 diff.

Looks like it's just the rowtypes.c ones that you have that I didn't
list. get_sql_insert() and FreeTupleDesc() were in my reject list.

The extra ones you've found seem to match a similar pattern to other
ones I did reject. The reason I left out the ones that could access
the CompactAttribute in one part of the function, but also *need* to
access the Form_pg_attribute in another part, was that I wasn't
certain it was going to be a win. One way it could be a net loss is
that now you need to load cachelines for both structs. It looks like
your changes to record_cmp(), record_eq() and record_image_eq() might
be more optimal in cases where the record has many dropped columns, as
that would allow us to skip fetching the Form_pg_attribute memory for
dropped columns. IMO, it doesn't seem like a good thing to optimise
for in exchange for additional overhead when there are no or few
dropped columns.

David



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: formatting.c cleanup
Next
From: Kirill Reshke
Date:
Subject: Re: Optimize SnapBuildPurgeOlderTxn: use in-place compaction instead of temporary array