Re: Problem with 8.4 stats collector high load

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Jakub Ouhrabka <kuba(at)comgate(dot)cz>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Problem with 8.4 stats collector high load
Date: 2010-02-16 19:55:50
Message-ID: 20100216195550.GM5330@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jakub Ouhrabka wrote:
> > Ideally, autovacuum would only request a new copy of the file if the
> > one it got was considerably out of date. Obviously a tenth of a
> > second is not old enough.
>
> I've tried to look at it and found that's already implemented - see
> autovac_refresh_stats(). STATS_READ_DELAY which is set to 1s. Am I
> reading the code correctly? If so then 1s is not enough for big
> clusters.

Note that it says it's not used for autovacuum workers; it's only used
for the autovacuum launcher. The workers have their own set of
problems, particularly the bit that two of them might choose to vacuum
the same table. I don't think this is so serious a problem in 8.4, so
maybe we could take out the check that limits it to the launcher.
However, it needs some thought.

You could try removing the "if" line and make it work unconditionally
and see if it fixes the problem for you, even at the 1s value.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dann Corbit 2010-02-16 19:56:48 Re: OpenVMS?
Previous Message Merlin Moncure 2010-02-16 19:34:28 Re: LISTEN/NOTIFY and notification timing guarantees