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