Tom Lane <t...@sss.pgh.pa.us> wrote: > Oleksii Kliukin <al...@hintbits.com> writes: >> Is there any interest in making autovacuum parameters available on a >> tablespace level in order to apply those to all vacuumable objects in the >> tablespace? > > I understand what you want to accomplish, and it doesn't seem > unreasonable. But I just want to point out that the situation with > vacuuming parameters is on the edge of unintelligible already; adding > another scope might push it over the edge. In particular there's no > principled way to decide whether an autovacuum parameter set at an outer > scope should override a plain-vacuum parameter set at a narrower scope.
My naive understanding is that vacuum and autovacuum should decide independently which scope applies, coming from the most specific (per-table for autovacuum, per-DB for vacuum) to the broader scopes, ending with configuration parameters at the outermost scope . Both *_cost_limit and *_cost_delay should be taken from the current vacuum scope only if effective autovacuum settings yield -1. > And it's really questionable which of database-wide and tablespace-wide > should be seen as a narrower scope in the first place. AFAIK we don’t allow setting autovacuum options per-database; neither I suggest enabling plain vacuum to be configured per-tablespace; as a result, we won’t be deciding between databases and tablespaces, unless we want to do cross-lookups from autovacuum to the outer scope of plain vacuum options before considering autovacuum’s own outer scope and I don’t see any reason to do that. > I don't know how to make this better, but I wish we'd take a step > back and think about it rather than just accreting more and more > complexity. I am willing to do the refactoring when necessary, any particular place in the code that is indicative of the issue? Regards, Oleksii Kliukin
