Re: Avoid extra "skipping" messages from VACUUM/ANALYZE

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Avoid extra "skipping" messages from VACUUM/ANALYZE
Date: 2022-12-30 20:01:37
Message-ID: 20221230200137.GA489582@nathanxps13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Tue, Dec 13, 2022 at 07:40:59PM -0800, Nathan Bossart wrote:
> Granted, this likely won't create as much noise as a database-wide VACUUM,
> but perhaps we could add a relkind check in expand_vacuum_rel() and swap
> the checks in vacuum_rel()/analyze_rel(), too. I don't know if it's worth
> the trouble, though.

I looked into this. I don't think adding a check in expand_vacuum_rel() is
worth much because we'd have to permit all relkinds that can be either
vacuumed or analyzed, and you have to check the relkind again in
vacuum_rel()/analyze_rel() anyway. It's easy enough to postpone the
permissions check in vacuum_rel() so that the relkind messages take
precedence, but if we do the same in analyze_rel(), FDWs'
AnalyzeForeignTable functions will be called prior to checking permissions,
which doesn't seem great. We could move the call to AnalyzeForeignTable
out of the relkind check to avoid this, but I'm having trouble believing
it's worth it to reorder the WARNING messages.

Ultimately, I think reversing the checks in get_all_vacuum_rels() (as your
patch does) should eliminate most of the noise, so I filed a commitfest
entry [0] and marked it as ready-for-committer.


Nathan Bossart
Amazon Web Services:

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2022-12-30 20:23:25 Re: Avoiding unnecessary clog lookups while freezing
Previous Message Tomas Vondra 2022-12-30 19:53:50 Re: Crash in BRIN minmax-multi indexes