>> I am wondering if we should take the current SQL used by vacuumdb to
>> find missing stats and perform direct syscache lookups in C?
>
>
> So....about that. The exiting missing-stats-only queries test for a corresponding
> pg_statistic_ext_data row for any pg_statistic_ext row that meets the relation filters,
> but at this very moment we can restore all types of extended stats _except_ expressions.
> That functionality could make it into 19, but if it doesn't we're going to have to adjust
> vacuumdb to probe pg_statistic_ext.stxkeys for expression indexes and look for
> matching stxdexprs elements. I agree that those matches are better done with
> syscache lookups, but the SQL that we're treating as a spec might be a moving
> target in the near future.
Eventually we will want vacuumdb to use the "ANALYZE (MISSING_STATS)" command
directly, rather than the SQL, but until the restore functionality
works for extended stats
of expressions, we will need to keep those separated. Did I understand
that correctly?
Yes, but no, but yes (eventually). :)
Yes, if we implemented ANALYZE(MISSING_STATS_ONLY), then yes, we'd want to leverage that that in vacuumdb once we know what versions it is available for, as what constitutes "missing" will change from version to version, and it would be nice to insulate vacuumdb from that. It will have to account for what "missing" meant in past versions though.
But before we get there, we have to contend with the fact that what constitutes "missing" has already subtly changed since v18, that change is not yet reflected in vacuumdb, and ideally the definition would change back to the v18 definition before v19 feature freeze, but that isn't guaranteed.
