Add starelid, attnum to pg_stats and leverage this in pg_dump
Corey Huinker <corey.huinker@gmail.com>
From: Corey Huinker <corey.huinker@gmail.com>
To: nathandbossart@gmail.com, pgsql-hackers@lists.postgresql.org
Date: 2026-02-25T21:22:06Z
Lists: pgsql-hackers
Attachments
- v1-0001-Add-attnum-and-starelid-columns-to-pg_stats.patch (text/x-patch) patch v1-0001
- v1-0002-pg_dump-Use-starelid-in-getAttributeStats.patch (text/x-patch) patch v1-0002
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
Commits
-
pg_dump: Simplify query for retrieving attribute statistics.
- 4b5ba0c4ca52 19 (unreleased) landed
-
Add more columns to pg_stats, pg_stats_ext, and pg_stats_ext_exprs.
- 3b88e50d6c2e 19 (unreleased) landed
-
Add convenience view to stats import test.
- 233bbdf031e4 19 (unreleased) landed