Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Oleksii Kliukin <alexk@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