> > 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?".
