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
signature.asc
Description: PGP signature
