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. [0] https://commitfest.postgresql.org/41/4094/ -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
