Hi, On Mon, Jul 13, 2026 at 11:06 PM Shinya Kato <[email protected]> wrote: > > 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. > > 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
Thanks. I came across the CF entry for this https://commitfest.postgresql.org/patch/6830/. Since you plan to discuss this in [1] which already has a CF entry, can we close this one? -- Bharath Rupireddy Amazon Web Services: https://aws.amazon.com
