| From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Hari Krishna Sunder <hari(dot)db(dot)pg(at)gmail(dot)com>, Robert Treat <rob(at)xzilla(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz>, jian he <jian(dot)universality(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Stephen Frost <sfrost(at)snowman(dot)net>, 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>, alvherre(at)alvh(dot)no-ip(dot)org |
| Subject: | Re: Statistics Import and Export |
| Date: | 2025-05-21 23:11:09 |
| Message-ID: | CADkLM=cTof2=WcB9+4TzwWs7qv7d_GYTaWNpG1JPCMs0oxOnvg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> I don't know precisely where that line might be, but in this case, the
> dumped stats have no hope of restoring into anything older than v18 (since
> the stats import functions won't exist), which is well past the point where
> we started using -1 for reltuples. If we could dump the stats from v13 and
> restore them into v13, then I think there would be a reasonably strong
> argument for dumping it as-is and reinterpreting as necessary during
> import. But I see no particular benefit from moving the complexity to the
> import side here.
>
Definitely keep complexity on the export-side.
Mapping reltuples 0 -> -1 if system version < 14 like the original patch
did makes the most sense to me. That allows vacuumdb to go back to ignoring
tables that are seemingly empty while still vacuuming the tables that had
the pre-14 suspicious 0 reltuples value.
>
> Does that seem like a reasonable position to you? Is there anything else
> we should consider?
>
Automatically vacuuming tables that purport to be empty may not take much
time, but it may alarm users using --missing-only, wondering why so many
tables didn't get stats imported, especially if we introduce a --dry-run
parameter which would answer for a user the question "what tables does
vacuumdb think are missing statistics?".
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Jones | 2025-05-21 23:15:57 | Re: [PATCH] Add pretty-printed XML output option |
| Previous Message | Masahiko Sawada | 2025-05-21 23:02:30 | Re: Fix slot synchronization with two_phase decoding enabled |