Re: autovacuum daemon question...

From: Jeff Bohmer <jdblist(at)visionlink(dot)org>
To: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>
Cc: Scott Marlowe <smarlowe(at)g2switchworks(dot)com>, Joe Maldonado <joe(dot)maldonado(at)gmail(dot)com>, pgsql-admin(at)postgresql(dot)org
Subject: Re: autovacuum daemon question...
Date: 2005-11-10 20:50:22
Message-ID: p06230900bf9961d37627@[192.168.1.200]
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin


>>Unless I misunderstand, if stats_reset_on_server_start=off, these
>>(currently nonexistent autovacuum) stats would only be relevant for
>>autovacuum's VACUUM activity and not it's ANALYZE activity. In
>>which case, it seems ideal to keep autovacuum VACUUM stats
>>regardless of the GUC setting, while autovacuum ANALYZE stats
>>should follow it. But if the ideal is impractical, making both
>>ANALYZE and VACUUM stats follow the GUC would still be real nice.
>
>I'm confused... the GUC var stats_reset_on_server_start dictates if
>the stats system dumps its data on DB restart. If we added a new
>table to the stats system kept track of autovacuum activity, then
>that data would also be dumped on restart if
>stats_reset_on_server_start=true.

Yep. I was thinking of a way to muck up the stats system by keeping
autovacuum's VACUUM activity irregardless of
stats_reset_on_server_start. Because autovacuum's VACUUM activity
data would be relevant across restarts, even if
stats_reset_on_server_start=true. But I see now that my idea is ugly
and just confuses things. I agree that having it work the way you
suggest is preferable.

- Jeff

--

Jeff Bohmer
VisionLink, Inc.

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Dongon, Ike C. 2005-11-11 07:13:49 Extending PG_DATA
Previous Message Matthew T. O'Connor 2005-11-10 20:41:35 Re: autovacuum daemon question...