pg.ddx.io pgsql-committers@postgresql.org mailing list archive
help / color / mirror / Atom feedpgsql: Use CompactAttribute more often, when possible
3+ messages / 3 participants
[nested] [flat]
* pgsql: Use CompactAttribute more often, when possible
@ 2025-10-21 22:36 David Rowley <drowley@postgresql.org>
0 siblings, 1 reply; 3+ messages in thread
From: David Rowley @ 2025-10-21 22:36 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Use CompactAttribute more often, when possible
5983a4cff added CompactAttribute for storing commonly used fields from
FormData_pg_attribute. 5983a4cff didn't go to the trouble of adjusting
every location where we can use CompactAttribute rather than
FormData_pg_attribute, so here we change the remaining ones.
There are some locations where I've left the code using
FormData_pg_attribute. These are mostly in the ALTER TABLE code. Using
CompactAttribute here seems more risky as often the TupleDesc is being
changed and those changes may not have been flushed to the
CompactAttribute yet.
I've also left record_recv(), record_send(), record_cmp(), record_eq()
and record_image_eq() alone as it's not clear to me that accessing the
CompactAttribute is a win here due to the FormData_pg_attribute still
having to be accessed for most cases. Switching the relevant parts to
use CompactAttribute would result in having to access both for common
cases. Careful benchmarking may reveal that something can be done to
make this better, but in absence of that, the safer option is to leave
these alone.
In ReorderBufferToastReplace(), there was a check to skip attnums < 0
while looping over the TupleDesc. Doing this is redundant since
TupleDescs don't store < 0 attnums. Removing that code allows us to
move to using CompactAttribute.
The change in validateDomainCheckConstraint() just moves fetching the
FormData_pg_attribute into the ERROR path, which is cold due to calling
errstart_cold() and results in code being moved out of the common path.
Author: David Rowley <dgrowleyml@gmail.com>
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://postgr.es/m/CAApHDvrMy90o1Lgkt31F82tcSuwRFHq3vyGewSRN=-QuSEEvyQ@mail.gmail.com
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/2470ca435c452fe4def9dcc4a831b5101691d541
Modified Files
--------------
contrib/dblink/dblink.c | 2 +-
contrib/file_fdw/file_fdw.c | 4 +---
contrib/postgres_fdw/deparse.c | 10 ++++------
src/backend/access/gin/gininsert.c | 2 +-
src/backend/commands/typecmds.c | 3 ++-
src/backend/optimizer/util/plancat.c | 2 +-
src/backend/parser/parse_relation.c | 8 ++++----
src/backend/replication/logical/reorderbuffer.c | 6 +-----
src/backend/replication/logical/worker.c | 5 +++--
src/backend/replication/pgoutput/pgoutput.c | 2 +-
src/backend/utils/adt/expandedrecord.c | 2 +-
src/backend/utils/adt/ruleutils.c | 4 ++--
src/backend/utils/cache/catcache.c | 5 +----
src/pl/plpython/plpy_typeio.c | 4 ++--
14 files changed, 25 insertions(+), 34 deletions(-)
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: pgsql: Use CompactAttribute more often, when possible
@ 2025-10-23 12:21 Robert Haas <robertmhaas@gmail.com>
parent: David Rowley <drowley@postgresql.org>
0 siblings, 1 reply; 3+ messages in thread
From: Robert Haas @ 2025-10-23 12:21 UTC (permalink / raw)
To: David Rowley <drowley@postgresql.org>; PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Tue, Oct 21, 2025 at 6:36 PM David Rowley <drowley@postgresql.org> wrote:
> There are some locations where I've left the code using
> FormData_pg_attribute. These are mostly in the ALTER TABLE code. Using
> CompactAttribute here seems more risky as often the TupleDesc is being
> changed and those changes may not have been flushed to the
> CompactAttribute yet.
David, I've noticed several times lately you've documented in commit
messages why you thought going further with some change would be
risky, and I really like that. I think sometimes we (as committers)
are sometimes reluctant to document cases where we weren't sure about
something or didn't know something, but IMHO this sort of
documentation of perceived risk is a huge help to anyone who is
thinking of working in this area later. Whether or not they agree with
your conclusions, they'll find it helpful to know your thought
process.
Thanks,
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: pgsql: Use CompactAttribute more often, when possible
@ 2025-10-23 18:43 David Rowley <dgrowley@gmail.com>
parent: Robert Haas <robertmhaas@gmail.com>
0 siblings, 0 replies; 3+ messages in thread
From: David Rowley @ 2025-10-23 18:43 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
On Fri, 24 Oct 2025 at 01:21, Robert Haas <robertmhaas@gmail.com> wrote:
> David, I've noticed several times lately you've documented in commit
> messages why you thought going further with some change would be
> risky, and I really like that. I think sometimes we (as committers)
> are sometimes reluctant to document cases where we weren't sure about
> something or didn't know something, but IMHO this sort of
> documentation of perceived risk is a huge help to anyone who is
> thinking of working in this area later. Whether or not they agree with
> your conclusions, they'll find it helpful to know your thought
> process.
Thanks. But part of that was from motivation to try and stop the
"hey, you forgot this one!" follow-up emails. :)
David
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2025-10-23 18:43 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-10-21 22:36 pgsql: Use CompactAttribute more often, when possible David Rowley <drowley@postgresql.org>
2025-10-23 12:21 ` Robert Haas <robertmhaas@gmail.com>
2025-10-23 18:43 ` David Rowley <dgrowley@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox