pg_restore handles extended statistics inconsistently with statistics data

From: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
Subject: pg_restore handles extended statistics inconsistently with statistics data
Date: 2026-06-11 03:31:26
Message-ID: 66E80CAB-527C-42B1-BB65-3F82CF4AD998@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

While testing “[c32fb29e9] Include extended statistics data in pg_dump”, I noticed that pg_dump and pg_restore behave asymmetrically for --statistics-only when a schema is specified.

This command dumps relation stats, attribute stats, and extended stats from the schema:
```
pg_dump --statistics-only -n s1 -f /tmp/plain-s1-stats.sql stats_src
```

However, this command will only restore extended stats for the schema:
```
pg_restore --statistics-only -n s1 -f /tmp/archive-s1-stats.sql /tmp/stats.dump
```

I tried the same test against 1ea44d7ddfb, the immediate predecessor of c32fb29e9. pg_dump dumped relation stats and attribute stats, while pg_restore restored nothing. So the asymmetric behavior for stats already existed. c32fb29e9 then added extended stats to both pg_dump and pg_restore, but the new EXTENDED STATISTICS DATA entries are handled differently from STATISTICS DATA during selective pg_restore, making the inconsistency visible.

The asymmetric behavior was not introduced by c32fb29e9, so I think we probably should not change that for v19. If it's confirmed that this needs to be fixed and nobody else plans to work on it, I would be happy to add it to my TODO list for v20.

For v19, I wonder if we should also exclude extended stats from selective pg_restore in the same way as other stats, so that EXTENDED STATISTICS DATA is treated consistently with STATISTICS DATA. That only requires a one-line change, see the attached exclude_ext_stats.diff. Actually, I suspect c32fb29e9 simply missed that change.

Also, attached test_pgdump_stats.sh is the script I ran to verify the problem.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

Attachment Content-Type Size
exclude_ext_stats.diff application/octet-stream 609 bytes
test_pgdump_stats.sh application/octet-stream 849 bytes

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2026-06-11 03:55:13 Re: (SQL/PGQ) Clean up orphaned properties when dropping a label
Previous Message cca5507 2026-06-11 03:16:03 Re: Bug? pg_rewind produces unusable but starting database with standby recovery