| 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-15 22:15:51 |
| Message-ID: | ajB5l1KikTPqhue-@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jun 15, 2026 at 03:25:39PM -0400, Corey Huinker wrote:
>> We cannot just add a strcmp(te->desc, "STATISTICS DATA") == 0 check to the
>> "else if (strcmp(te->desc, "INDEX") == 0)" branch, because STATISTICS DATA
>> would already have matched the earlier table branch. So in v4, I pulled
>> STATISTICS DATA into its own branch before the table and index branches.
>
> v4 is looking good, though I'm a bit frustrated that that `pg_dump -s -t
> s1.t` will include the index creations but not not the extended stats
> objects. Feels like an oversight.
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.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2026-06-15 22:24:35 | Re: [PATCH] Add cascade synchronous replication |
| Previous Message | Pavel Borisov | 2026-06-15 21:56:50 | Re: Add SPLIT PARTITION/MERGE PARTITIONS commands |