Re: Per table autovacuum vacuum cost limit behaviour strange

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Per table autovacuum vacuum cost limit behaviour strange
Date: 2014-10-03 00:35:26
Message-ID: 20141003003526.GE28859@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Alvaro Herrera (alvherre(at)2ndquadrant(dot)com) wrote:
> Alvaro Herrera wrote:
> > Basically, if you are on 9.3.5 or earlier any per-table options for
> > autovacuum cost delay will misbehave (meaning: any such table will be
> > processed with settings flattened according to balancing of the standard
> > options, _not_ the configured ones). If you are on 9.3.6 or newer they
> > will behave as described in the docs.
>
> Another thing to note is that if you have configured a table to have
> cost_limit *less* than the default (say 150 instead of the default 200),
> the balance system will again break that and process the table at 200
> instead; in other words, the balancing system has completely broken the
> ability to tweak the cost system for individual tables in autovacuum.

That's certainly pretty ugly.

> With the v5 patch, the example tables above will be vacuumed at exactly
> 5000 and 150 instead. The more complex patch I produced earlier would
> have them vacuumed at something like 4900 and 100 instead, so you
> wouldn't exceed the total of 5000. I think there is some value to that
> idea, but it seems the complexity of managing this is too high.

Agreed.

> I am rather surprised that nobody has reported this problem before. I
> am now of the mind that this is clearly a bug that should be fixed all
> the way back.

I'm coming around to that also, however, should we worry about users who
set per-table settings and then simply forgot about them? I suppose
that won't matter too much unless the table is really active, and if it
is, they've probably already set it to zero.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marti Raudsepp 2014-10-03 00:38:27 Re: Patch to add support of "IF NOT EXISTS" to others "CREATE" statements
Previous Message Peter Geoghegan 2014-10-03 00:26:51 Re: Fixed xloginsert_locks for 9.4