Skip site navigation (1) Skip section navigation (2)

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@[] (view raw, whole thread or download thread mbox)
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 

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


pgsql-admin by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group