Re: Statistics Import and Export - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: Statistics Import and Export
Date
Msg-id CADkLM=cTof2=WcB9+4TzwWs7qv7d_GYTaWNpG1JPCMs0oxOnvg@mail.gmail.com
Whole thread Raw
In response to Re: Statistics Import and Export  (Nathan Bossart <nathandbossart@gmail.com>)
List 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?".


pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Fix slot synchronization with two_phase decoding enabled
Next
From: Jeff Davis
Date:
Subject: Re: Statistics Import and Export