Re: Optional skipping of unchanged relations during ANALYZE?

On Thu, Jan 29, 2026 at 5:24 PM Sami Imseih <samimseih(at)gmail(dot)com> wrote:

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