Re: Proposal: ANALYZE (MODIFIED_STATS) using autoanalyze thresholds

On Tue, Feb 24, 2026 at 08:45:26AM -0500, Corey Huinker wrote:
> 1. The view would need to expose pg_class.oid so that it could be joined to
> the listed_object CTE. Our pattern seems to be schemaname+tablename with no
> exposed oids, something that has caused a problem in the past, namely in
> pg_dump when batching attribute stats. Is exposing oids in these views a
> no-no?

I don't think so. Counterexamples include pg_stat_activity,
pg_stat_subscription, pg_stat_database, pg_stat_all_tables, and more. If
anything, maybe we should consider _adding_ oid columns to views like
pg_stats_ext...

> 2. The view either needs the pg_class.oid to join back to pg_class to get
> relkind, relpersistence, relfrozenxid, relminmxid, etc...or it needs to
> expose those columns as a part of the view, which would be problematic when
> vacuumdb and other apps decide that they need to filter on some other part
> of pg_class, and then we've got different versions of the system view which
> makes that option highly unattractive.

Hm. I don't know how much to worry about this. System view/catalog
changes do happen from time to time, so unless we have a bunch of possible
changes that will happen soon, I'd expect it to probably be okay.

> If we instead did a system function `pg_rel_is_missing_stats(oid) returns
> boolean`, but it would still need to sanity check on relkind and filter on
> relpersistence and inherited.

Couldn't the function handle those sanity checks?

--
nathan