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