| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
| Subject: | Re: Statistics Import and Export |
| Date: | 2024-03-30 17:29:43 |
| Message-ID: | cea2d432215847a1d5cef1422ad1b21814f3f73b.camel@j-davis.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, 2024-03-30 at 13:18 -0400, Tom Lane wrote:
> Surely they are data, not schema. It would make zero sense to
> restore
> them if you aren't restoring the data they describe.
The complexity is that pg_upgrade does create the data, but relies on a
schema-only dump. So we'd need to at least account for that somehow,
either with a separate stats-only dump, or make a special case in
binary upgrade mode that dumps schema+stats (and resolves the CREATE
INDEX issue).
> Maybe we need to revisit CREATE INDEX's behavior rather
> than assuming it's graven in stone?
Would there be a significant cost to just not doing that? Or are you
suggesting that we special-case the behavior, or turn it off during
restore with a GUC?
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2024-03-30 17:39:40 | Re: Statistics Import and Export |
| Previous Message | Tom Lane | 2024-03-30 17:18:54 | Re: Statistics Import and Export |