Re: [PG19] pg_dump --statistics restores extended statistics by attribute number

On Tue, Oct 13, 2026 at 12:06:06AM -0400, shihao zhong wrote:
> It is silent when the numbers are still valid but mean other columns.
> That happens for an inheritance child whose columns are in another
> order than the parent, because pg_dump recreates it with the order of
> the parent. The statistics then land on other columns.

Yeah, logical vs physical column ordering has been an old problem in
Postgres, because the way attnums are logically ordered may not
reflect with the way pg_dump tries to restore these relations. See
for example this thread, explaining partially why it is a complicated
problem:
https://www.postgresql.org/message-id/20141209174146.GP1768%40alvh.no-ip.org

The point here is that extended statistics have been always relying on
these numbers internally, strictly positive for attributes, and
strictly negative for expressions.

> 0001 adds two optional arguments to pg_restore_extended_stats, the
> source column numbers and the column names of the statistics object,
> and maps the numbers by name. 0002 makes pg_dump pass them. 0003 adds
> tests. The MCV list is stored by column position, so 0001 skips it
> with a warning when the order differs.

Note that what you are introducing here has also its own set of
problems. Renaming of a column to have the same name as a previous
column would be one. A second potential problem is I suspect that
pg_dump may always restore the tables based on the attribute order you
are trying to force based on the inputs of your new stxkeys and
stxkeynames arguments given to pg_restore_extended_stats(). Rejection
is probably the best thing we can do here, because the extended stats
we are trying to insert do not match with what pg_dump has been
restoring. In short, while I kind of agree that it is a problem based
on the attnum pattern, there is more to it than what you are assuming,
and it's probably not worth spending dozens of hours on at the end.
--
Michael