Re: Proposal: ANALYZE (MODIFIED_STATS) using autoanalyze thresholds

>
> Yeah, I'm not at all excited about adding options to ANALYZE for this
> sort of thing either. I agree with the VIEW idea. If we had the vacuum
> scoring stuff, I imagined it'd be useful to have a view that lists
> tables and their vacuum/analyze score.

Several of the stats import iterations that never made it to commits had
exportable stats view, so I took a stab at making pg_missing_stats, and a
couple of problems emerged.

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

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.

So either way we're doing some self-joins on pg_class, probably with a
security barrier.