On Sat, Jun 27, 2026 at 3:53 PM Bharath Rupireddy <[email protected]> wrote: > Can we avoid adding a GUC just for this? If we agree it's worth > emitting this information, after clarifying what exactly to tune when > this situation is hit, then maybe we could just add it to > pg_stat_all_tables instead - something like > autovacuum_concurrent_skip_count, similar to autovacuum_count and its > friends - and explain nicely in the docs what to look for when this > counter starts growing for a table.
I like this better than the GUC. A growing per-table counter is something a DBA can watch over time and reason about. So I would like to drop the GUC and pursue a per-table counter instead. That surface is already being built in the "Track skipped tables during autovacuum and autoanalyze" thread [1], which adds skipped-vacuum and skipped-analyze counters to pg_stat_all_tables for tables skipped when a lock cannot be acquired. I raised the concurrent-worker skip there [2] as another skip reason worth tracking on the same surface. It needs its own discussion, so I plan to take it up in that thread or start a new one, rather than here. [1] https://www.postgresql.org/message-id/20260324151133.7940a5c1f2ebd594d54da481%40sraoss.co.jp [2] https://www.postgresql.org/message-id/CAOzEurSn7YDLLNnZW6etRJ167ZG4hvdaYDxeX5qwy%2BtuOFe4Dw%40mail.gmail.com -- Best regards, Shinya Kato NTT OSS Center
