Hi, >> 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. > > 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.
It seems like this thread is now discussing both the modified stats option ( this thread ) and the skipped stats option [1], which will be hard to follow. But from a high-level, I am not sure how providing a VIEW or functions in which users will be required to script out the ANALYZE commands to run is better than providing ANALYZE options? the difference is putting the burden on the user to come up with the SQL script vs a simple ANALYZE option. IMO, the latter is more appealing from a user perspective. I think the view is a good idea, and this was discussed a bit here [2], if we do implement a scoring algorithm, but this view will be more for monitoring/visibility. [1][https://www.postgresql.org/message-id/cae2r8h61ztt4ek3jmlkdpmr7alq0ue9wswwjrfhbxm0wdoj...@mail.gmail.com] [2][https://www.postgresql.org/message-id/CAApHDvpVE5F-_8rpPC%2B-L98mA0yK0S_jtQGqLn69fkRevf726g%40mail.gmail.com] -- Sami Imseih Amazon Web Services (AWS)
