| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
| Cc: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com> |
| Subject: | Re: pg_restore handles extended statistics inconsistently with statistics data |
| Date: | 2026-06-16 02:07:22 |
| Message-ID: | ajCv2umDUeJiHtoz@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jun 16, 2026 at 07:15:51AM +0900, Michael Paquier wrote:
> That's the behavior since v15. Contrary to you, the behavior of
> specifying a table in pg_dump and pg_restore but not including a stats
> definition makes more sense here. The reasoning is that a stats
> object may live on a different schema than the table it is defined on,
> so you cannot guarantee that its schema has been created if you only
> create a table on a schema.
Sharing the check for a STATISTICS DATA TOC entry on table and index
names was making me ticking a bit, as this is not entirely
collision-proof for the names, but it also looks like we do things the
same way with TABLE DATA and INDEX, so.. At the end, applied down to
v18 as suggested.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Corey Huinker | 2026-06-16 02:53:22 | Re: pg_restore handles extended statistics inconsistently with statistics data |
| Previous Message | Ewan Young | 2026-06-16 02:02:15 | Re: REPACK CONCURRENTLY fails on tables with generated columns |