Re: Per table autovacuum vacuum cost limit behaviour strange - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Per table autovacuum vacuum cost limit behaviour strange
Date
Msg-id CA+TgmoYn=Q9LRO_w0_BamZy2u+39UQiDc66sTq4rg6RV1xrvAg@mail.gmail.com
Whole thread Raw
In response to Re: Per table autovacuum vacuum cost limit behaviour strange  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Tue, Sep 30, 2014 at 6:16 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Robert Haas wrote:
>> I favor option (a).   There's something to be said for your proposal
>> in terms of logical consistency with what we have now, but to be
>> honest I'm not sure it's the behavior anyone wants (I would welcome
>> more feedback on what people actually want).  I think we should view
>> an attempt to set a limit for a particular table as a way to control
>> the rate at which that table is vacuumed - period.
>
> After re-reading this whole thread one more time, I think I have come to
> agree with you and Amit here, because not only it is simpler to
> implement, but it is also simpler to document.  Per Greg Smith's opinion
> elsewhere in the thread, it seems that for end users it doesn't make
> sense to make the already complicated mechanism even more complicated.
>
> So in essence what we're going to do is that the balance mechanism
> considers only tables that don't have per-table configuration options;
> for those that do, we will use the values configured there without any
> changes.
>
> I'll see about implementing this and making sure it finds its way to
> 9.4beta3.

Cool!

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)
Next
From: Robert Haas
Date:
Subject: Re: autovacuum scheduling starvation and frenzy