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
checkon 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/CAE2r8H61ZtT4ek3JmLKDPmr7ALQ0uE9WSwwJRFHbXm0WdOJnEQ@mail.gmail.com]
[2][https://www.postgresql.org/message-id/CAApHDvpVE5F-_8rpPC%2B-L98mA0yK0S_jtQGqLn69fkRevf726g%40mail.gmail.com]
--
Sami Imseih
Amazon Web Services (AWS)
