| From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| 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 04:14:16 |
| Message-ID: | CADkLM=duaKbs5bjMJ4YUGkiEOjAjKMeiU_pC-_ciC6ppGqH+UA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> pg_restore --index is as old as e8f69be054e9, so it's not like we
> could just remove it, but I'd say that with the schema-level restore
> this would be tempting.
>
That temptation tells me that there is no appetite for a similar flag for
named extended stats objects, which makes me wonder how somebody would get
all of the extended stats objects and the pg_restore_extended_stats() calls
for a given table, aside from manually filtering the output of a --no-data
--statistics dump. It's not a very common use case right now, but I suspect
the cases for it will increase in the future.
>
> Anyway, let's improve this situation with the attached, for HEAD and
> v18.
+1 to this.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dilip Kumar | 2026-06-16 04:25:55 | Re: Proposal: Conflict log history table for Logical Replication |
| Previous Message | shveta malik | 2026-06-16 04:13:19 | Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication |