Re: Problem with 8.4 stats collector high load - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Problem with 8.4 stats collector high load
Date
Msg-id 20100216195550.GM5330@alvh.no-ip.org
Whole thread Raw
In response to Re: Problem with 8.4 stats collector high load  (Jakub Ouhrabka <kuba@comgate.cz>)
List 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.


pgsql-hackers by date:

Previous
From: Jakub Ouhrabka
Date:
Subject: Re: Problem with 8.4 stats collector high load
Next
From: Kevin Ar18
Date:
Subject: