From: | Oleksii Kliukin <alexk(at)hintbits(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Per-tablespace autovacuum settings |
Date: | 2019-02-14 19:46:38 |
Message-ID: | 30EB6884-9E1B-41F3-A832-C4F4077DDB3E@hintbits.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Oleksii Kliukin <alexk(at)hintbits(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2019-02-14 19:55:01 | Re: explain plans with information about (modified) gucs |
Previous Message | Andres Freund | 2019-02-14 19:40:29 | Re: make installcheck-world in a clean environment |