| 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 |
| 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 |