Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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                      
The PostgreSQL Company - Command Prompt, Inc.

In response to

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group