pg_dump: ALTER INDEX SET STATISTICS missing for index-backed constraints
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
This thread has been committed, so CI has stopped here. Anything below is the last result it produced.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253075psql -h localhost -U postgresBuilt from patchset v4 (message #4), October 01, 2026 at 12:03 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253075_4 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253075_4 && git checkout t253075_4Patchset v4 (message #4) is on t253075_4
Hello hackers,
I noticed this while reviewing the pg_get_tale_ddl patch and looking
for inconsistencies compared to pg_dump.
It seems like pg_dump emits SET STATISTICS for most cases since 2018
(e4fca461), but it was missed in this case:
CREATE TABLE t (a int, b int);
ALTER TABLE t ADD CONSTRAINT name EXCLUDE USING gist ((a+b) WITH =);
ALTER INDEX name ALTER COLUMN 1 SET STATISTICS 900;
The last statement was missing from the pg_dump output.
Attached patch fixes it and adds a test case.
Hi,
The last statement was missing from the pg_dump output.
The fix looks good to me. I applied your patch to d9b5a63f49 and
built with assertions enabled on macOS arm64. The pg_dump and
pg_upgrade suites passed. The new test fails without the C change
and passes with it.
I also checked restores from plain, custom, directory and tar dumps,
including parallel restore and restore as a non-superuser owner.
Statistics targets were preserved for multiple expressions, quoted
and renamed indexes, and values 0 and 10000. A same-version
pg_upgrade preserved them too.
The test could also use different targets for expression columns 1
and 3, with a plain column between them, as the existing
ordinary-index test does. That would also cover pairing the column
numbers with their targets. I tried this case separately and
it works with the patch.
I found the same omission in REL_14_STABLE through REL_19_STABLE by
code inspection; I haven't built or tested those branches. I think
this should be backpatched through 14.
This looks ready for a committer.
Best regards,
Andrew Krylosov
On Jul 14, 2026, at 20:45, Zsolt Parragi <zsolt.parragi@percona.com> wrote:
Hello hackers,
I noticed this while reviewing the pg_get_tale_ddl patch and looking
for inconsistencies compared to pg_dump.It seems like pg_dump emits SET STATISTICS for most cases since 2018
(e4fca461), but it was missed in this case:CREATE TABLE t (a int, b int);
ALTER TABLE t ADD CONSTRAINT name EXCLUDE USING gist ((a+b) WITH =);
ALTER INDEX name ALTER COLUMN 1 SET STATISTICS 900;The last statement was missing from the pg_dump output.
Attached patch fixes it and adds a test case.
<0001-Dump-index-column-statistics-for-index-backed-constr.patch>
The patch looks good to me overall. My only nit is that it adds more dup code to dumpIndex(). Maybe we could factor that out into a small helper function shared by dumpIndex() and dumpConstraint().
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
Thank you for the reviews, I addressed both concerns in v2.
On Thu, Oct 01, 2026 at 12:50:47PM +0100, Zsolt Parragi wrote:
Thank you for the reviews, I addressed both concerns in v2.
I was just wondering if this was intentional and look at the committer
name in the commit I've found: e4fca461ab6f. :D
Agreed that this had better be backpatched down to all the supported
branches, we (I) did that last time as that's annoying to not have
this data dumped and restored. On top of that the information is
already available thanks to the indxinfo, meaning that it's already
there for free.
Will take care of it, with some adjustments to the comments. Thanks
for the report!
--
Michael