Re: tuning autovacuum - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: tuning autovacuum
Date
Msg-id BANLkTikU=PE2X8i=_Jgtabj0ObD22fp8HQ@mail.gmail.com
Whole thread Raw
In response to tuning autovacuum  (Euler Taveira de Oliveira <euler@timbira.com>)
List pgsql-hackers
<p>On Jun 9, 2011 12:01 AM, "Euler Taveira de Oliveira" <<a
href="mailto:euler@timbira.com">euler@timbira.com</a>>wrote:<br /> ><br /> > Hi,<br /> ><br /> > There
aresome releases that autovacuum was enabled by default and, up to now there is an easy way to estimate the number of
autovacuumworkers. I tune it observing if the number of slots are saturated for a period of time. I'm having a hard
timetrying to do this. I want to add a LOG message such as<br /> ><br /> > LOG: maximum number of autovacuum
workersreached<br /> > HINT: Consider increasing autovacuum_max_workers (currently 5).<p>That would be very
useful.<br/><p>> And also a view (say pg_stat_autovacuum) to expose some autovacuum information such as (i) number
ofautovacuum workers (ii) number of tables that needs analyze/vacuum and are scheduled to (iii) number of<p>Part of
thatis on my personal todo already, so I'd be happy to review that :)<p>> autovacuum count (iv) number of
autoanalyzecount. While I am in this topic, it would be nice to expose the analyze/vacuum count and threshold per
table.This information should go to pg_stat_*_tables but it already has too much fields. Maybe it is time to split
autovacuuminformation into another statistic view?<p>That is configuration information and not statistics, so IMHO it
doesnot belong in pg_stat_*.<p>And if relation parameters are to be exposed more than they are now it should be done
forall, not just autovacuum.<p>/Magnus<br /> 

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: reducing the overhead of frequent table locks - now, with WIP patch
Next
From: Tom Lane
Date:
Subject: Re: reducing the overhead of frequent table locks - now, with WIP patch