Re: More vacuum stats - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: More vacuum stats
Date
Msg-id AANLkTikvnHfb2X8v7DHWdB7FrmAB75L2M9T4a-iU5djd@mail.gmail.com
Whole thread Raw
In response to Re: More vacuum stats  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: More vacuum stats
List pgsql-hackers
On Sun, Aug 22, 2010 at 17:29, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> I noticed that we were already tracking the information about when an
>> autovacuum worker was last started in a database, but this information
>> was not exposed. The attached patch puts this column in
>> pg_stat_database.
>
>> Was there any particular reason why this wasn't exposed before that
>> I've missed, making this a bad addition? :-)
>
> I think that's an implementation detail.  If we expose it then we'll
> be forced to track it forevermore, regardless of whether the AV launcher
> actually needs it in the future.  (In particular, the assumption that
> this is tracked per-database and not per-something-else seems like an
> artifact of the current AV launching algorithm.)

That's a good point. OTOH, if we removed the feature, it seems it
would be reasonable to remove the column from the statistics view as
well. That *could* happen in other stats views as well.

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

You need to connect to every database to do that. If you have many
databases, that's a lot of overhead particularly if you're doing tihs
for regular monitoring. Plus, those views will only track when
autovacuum actually *did* something.

Being able to see that autovacuum hasn't even touched a database for
too long would be an early-indicator that you have some issues with
it.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Replacing the pg_get_expr security hack with a datatype solution
Next
From: Tom Lane
Date:
Subject: Re: More vacuum stats