| From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
|---|---|
| To: | nathandbossart(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Add starelid, attnum to pg_stats and leverage this in pg_dump |
| Date: | 2026-02-25 21:22:06 |
| Message-ID: | CADkLM=coCVy92QkVUUTLdo5eO2bMDtwMrzRn_8miAhX+uPaqXg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Per side conversation in [1], this patch exposes pg_statistic.starelid in
the pg_stats view (0001) and then changes pg_dump to use the starelid in
the queries on pg_stats rather than the combination of schemaname+relname,
which gets a bit clumsy in bulk array fetching, and also leads to bad query
plans against pg_stats because the security barrier is also an optimization
barrier, which means that queries often try to hash join, which causes the
very large table pg_statistic to be sequentially scanned, and that's a bad
time. Currently we get around this by adding a redundant qual to the query
which gooses the plan towards an index, and that works fine for now, but
there's no guarantee that it will continue to work in the future, so this
change brings some plan safety as well.
0001 also exposes pg_statistic.attnum. This is no direct application of
this in 0002, but people have often expressed surprise that pg_dump orders
the pg_restore_attribute_stats() calls by attname rather than attnum, and
if we wanted to change that now we could (albeit only on new versions).
[1] https://www.postgresql.org/message-id/aZ3RbTE8Racscykc@nathan
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Add-attnum-and-starelid-columns-to-pg_stats.patch | text/x-patch | 76.3 KB |
| v1-0002-pg_dump-Use-starelid-in-getAttributeStats.patch | text/x-patch | 8.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matheus Alcantara | 2026-02-25 21:29:23 | Re: Initial COPY of Logical Replication is too slow |
| Previous Message | Euler Taveira | 2026-02-25 21:19:27 | Re: [PATCH] Add pg_get_database_ddl() function to reconstruct CREATE DATABASE statement |