Re: pg_restore handles extended statistics inconsistently with statistics data
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Corey Huinker <corey.huinker@gmail.com>
Cc: Chao Li <li.evan.chao@gmail.com>, PostgreSQL-development <pgsql-hackers@lists.postgresql.org>, Michael Paquier <michael.paquier@gmail.com>, Jeff Davis <pgsql@j-davis.com>
Date: 2026-06-15T22:15:51Z
Lists: pgsql-hackers
On Mon, Jun 15, 2026 at 03:25:39PM -0400, Corey Huinker wrote: >> We cannot just add a strcmp(te->desc, "STATISTICS DATA") == 0 check to the >> "else if (strcmp(te->desc, "INDEX") == 0)" branch, because STATISTICS DATA >> would already have matched the earlier table branch. So in v4, I pulled >> STATISTICS DATA into its own branch before the table and index branches. > > v4 is looking good, though I'm a bit frustrated that that `pg_dump -s -t > s1.t` will include the index creations but not not the extended stats > objects. Feels like an oversight. That's the behavior since v15. Contrary to you, the behavior of specifying a table in pg_dump and pg_restore but not including a stats definition makes more sense here. The reasoning is that a stats object may live on a different schema than the table it is defined on, so you cannot guarantee that its schema has been created if you only create a table on a schema. -- Michael
Commits
-
pg_restore: Use dependency-based matching for STATISTICS DATA
- 477efef089c3 18 (unreleased) landed
- ae39bd23c662 19 (unreleased) landed
-
Fix inconsistencies with pg_restore --statistics[-only]
- 42ffdedcf743 18 (unreleased) landed
- 0dd93de69e80 19 (unreleased) landed