Hi, On Sat, Mar 28, 2026 at 10:54 AM Sami Imseih <[email protected]> wrote: > > > 4. Is the view intended to be exposed to PUBLIC without any ACL > > restrictions? > > > 2/ Do we need to revoke permissions on pg_stat_get_autovacuum_priority > > for all and grant them to pg_monitor or similar? Especially since this > > function loops over all the relations in a database, we may not want > > everyone to be able to do this. > > I think you're correct there. While the data is not sensitive, it > should have more controlled usage. It's only taking an AccessShareLock, > but you would not want anyone to be able to run this since it's > doing real computation. I think requiring pg_read_all_stats > is a good idea. Will do.
+1 for pg_read_all_stats. > > Can we have the per-relation prioritization computation function in C > > and provide a per-database computation function as a SQL function over > > this per-relation function in system_functions.sql? > > Yes, perhaps we should do this. So we can have a function called > pg_stat_get_autovacuum_priority() that either takes a NULL or an OID > to either return all the tables or just a single table. > This is a similar usage pattern as pg_stat_get_subscription or > pg_stat_get_activity. > > pg_stat_autovacuum_priority will be a view that wraps around the NULL > variant of the function. > > The case where the OID is passed we just do a SearchSysCache1(RELOID,...) > whereas the other case will do the full catalog scan. > > What do you think? IMHO, we can have pg_stat_get_relation_autovacuum_priority defined as a C function to give the autovacuum scoring as of the given moment for the given table. It's easy for one to write a function to get scoring for all the relations in a database. This keeps things simple yet useful. -- Bharath Rupireddy Amazon Web Services: https://aws.amazon.com
