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.
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 |