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