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

On Tue, Oct 13, 2026 at 12:56 AM shihao zhong <zhong950419(at)gmail(dot)com> wrote:

> Hi Michael,
>
> Thanks for the quick reply and the pointer.
>
> I agree 19 is not the place for a big change, so rejection works for me.
>
> The dropped column case is rejected today, that is the warning in my
> first mail. The child with another column order is not. Its numbers are
> valid for the restored table, so the data lands on other columns.
>
> v2 drops the mapping and only rejects that case. pg_dump passes the
> column names of the statistics object, and the restore function skips
> the data when they are not the names of its own columns in the same
> order. The child then gets
>
> WARNING: could not restore extended statistics object
> "public.ch_s": its columns do not match "attnames"
>
> Thanks,
> Shihao
>

I agree with Michael that this seems like a lot of work to restore some
statistics that will be overwritten on the next autovacuum, the table
itself would be caught by vacuumdb --missing-stats-only if the stats were
rejected, and in the case where the stats applied then we can generate a
list of suspect tables from the old database based on which tables had a
dropped column in them.

While it would be theoretically possible to teach pg_dump to remap
attribute numbers to account for dropped columns, thus mapping the attnums
in pg_ndistinct and pg_dependencies to their destination numbers, but that
would complicate pg_dump and require the user to specify whether they
wanted these stats to apply to the existing table structure or the rebuilt
one. In that case, the better thing would be to capture the JSON for the
suspect extended stats objects, programmatically replace the affected
attnums, and then re-apply those stats manually, but even that seems like a
lot of work.

Additionally, the ongoing work in join statistics is also considering a
refactor of how statistic columns and expressions are stored [1], which may
or may not make this problem more tractable. Either way it will be
different and we will have to account for that.

[1]
https://www.postgresql.org/message-id/CAK98qZ3H9HBJaUHD-Y8Y%3D%3D3bzoP4kP%2Bp5oqySWqHwqAipqUTBg%40mail.gmail.com