| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(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-21 19:26:44 |
| Message-ID: | 5e94c358caedf2a231dd71624c3578db7227a265.camel@j-davis.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 2024-03-21 at 15:10 -0400, Corey Huinker wrote:
>
> In which case wouldn't the checkCanModify on pg_statistic would be a
> proxy for is_superuser/has_special_role_we_havent_created_yet.
So if someone pg_dumps their table and gets the statistics in the SQL,
then they will get errors loading it unless they are a member of a
special role?
If so we'd certainly need to make --no-statistics the default, and have
some way of skipping stats during reload of the dump (perhaps make the
set function a no-op based on a GUC?).
But ideally we'd just make it safe to dump and reload stats on your own
tables, and then not worry about it.
> Not off hand, no.
To me it seems like inconsistent data to have most_common_freqs in
anything but descending order, and we should prevent it.
> >
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Corey Huinker | 2024-03-21 19:33:29 | Re: Statistics Import and Export |
| Previous Message | Amonson, Paul D | 2024-03-21 19:17:54 | RE: Popcount optimization using AVX512 |