From: | Greg Smith <greg(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: More vacuum stats |
Date: | 2010-08-23 14:28:28 |
Message-ID: | 4C72858C.6020100@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> So I'd like to see a positive argument why this is important for users
> to know, rather than merely "we should expose every conceivable detail
> by default". Why wouldn't a user care more about last AV time for a
> specific table, which we already do expose?
>
What I actually want here is for the time that the last table autovacuum
started, adding to the finish time currently exposed by
pg_stat_user_tables. "How long did the last {auto}vacuum on <x> take to
run?" is a FAQ on busy systems here. If I could compute that from a
pair of columns, it's a major step toward answering even more
interesting questions like "how does this set of cost delay parameters
turn into an approximate MB/s worth of processing rate on my tables?".
This is too important of a difficult tuning exercise to leave to log
scraping forever.
I'd rather have that and look at for "SELECT max(last_autovacuum_start)
FROM pg_stat_user_tables" to diagnose the sort of problems this patch
seems to aim at helping.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.us
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2010-08-23 14:32:21 | Re: More vacuum stats |
Previous Message | Tom Lane | 2010-08-23 14:14:38 | Re: patch (for 9.1) string functions |