Re: More vacuum stats

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: More vacuum stats
Date: 2010-08-23 14:04:14
Message-ID: 19973.1282572254@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Sun, Aug 22, 2010 at 18:17, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> With the current AV launch algorithm, unless you have very serious
>> system-wide issues there will be a worker launched into each database
>> approximately every autovacuum_naptime seconds. AFAICS this does not
>> tell you anything interesting about whether AV is getting its work done.

> Well, if you have all your autovacuum workers tied up with vacuuming
> large tables, then it wouldn't AFAIK. I'm not sure if that counts as
> your "very serious system-wide issues", but it's certainly a case
> that's interesting for the admin to know about.

> But thinking more about that, you ca nfigure that out with a SELECT
> count(*) FROM pg_stat_activity WHERE current_query LIKE 'autovacuum:
> %' if I'm not mistaken.

> It can also be used to find out if the launcher is somehoiw stuck, but
> that would be a bug and we don't generally put counters in the stats
> views to expose possible bugs, only to track interesting statistics.

Yeah. Given the current worker-launch algorithm, these times just don't
strike me as all that interesting in practice. If we were to change to
a different algorithm, it's possible that it'd become worthwhile to
expose them --- but it's equally possible that some other data would be
useful instead. So my feeling remains that we should leave well enough
alone.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-08-23 14:14:38 Re: patch (for 9.1) string functions
Previous Message Robert Haas 2010-08-23 14:03:54 Re: [BUGS] BUG #5305: Postgres service stops when closing Windows session