Added to TODO for autovacuum:
o Consider logging activity either to the logs or a system view
---
Jeff Bohmer wrote:
>
> >>Unless I misunderstand, if stats_reset_on_server_start=off, these
> >>(currently nonexist
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
Jeff Bohmer wrote:
I assumed (perhaps incorrectly) that you were talking about
maintaining the data in the theoretical / not yet in existence
autovacuum stats table through database restart, the stats system
already has a GUC var that dictates whether or not it dumps it's data
upon DB restart
AFAIK, a restart does not affect the VACUUMed-ness of anything.
Keeping these (currently nonexistent autovacuum) stats across
restarts would be helpful if stats_reset_on_server_start=on.
Sorry, got the meaning backwards. The above should be
stats_reset_on_server_start=OFF. And the below s
This sounds more and more like a good idea. I don't think there's any
need to maintain across dump/reload and / or database restart either.
The DBA can elect to keep or discard stats data across DB restart,
in fact I think the default value for this GUC var was set to true
for the 8.1 releas
Scott Marlowe wrote:
On Thu, 2005-11-10 at 09:56, Matthew T. O'Connor wrote:
Scott Marlowe wrote:
I would appreciate an easy way to keep tabs on autovacuum's activity.
A stat table seems like a practical way to have this info readily
available.
No need to keep values across dump/relo
On Thu, 2005-11-10 at 09:56, Matthew T. O'Connor wrote:
> Scott Marlowe wrote:
> >> I would appreciate an easy way to keep tabs on autovacuum's activity.
> >> A stat table seems like a practical way to have this info readily
> >> available.
> >>
> >> No need to keep values across dump/reloads, ri
Scott Marlowe wrote:
I would appreciate an easy way to keep tabs on autovacuum's activity.
A stat table seems like a practical way to have this info readily
available.
No need to keep values across dump/reloads, right?
This sounds more and more like a good idea. I don't think there's a
On Thu, 2005-11-10 at 02:04, Jeff Bohmer wrote:
> >Another thought: How about adding something to the stats system
> >that an admin can turn on / off. Maybe anew relation called
> >pg_stat_autovacuum_activity this would detail the last vacuum, last
> >analyze, number of vacuums / analyzes in t
Another thought: How about adding something to the stats system
that an admin can turn on / off. Maybe anew relation called
pg_stat_autovacuum_activity this would detail the last vacuum, last
analyze, number of vacuums / analyzes in the last 24 hours, last
month etc... I dunno, whatever pe
Tom Lane wrote:
This would be a pretty bad idea IMHO, since it would lead to bloating
the logs with autovacuum progress messages by default --- and whatever
you may think about it, I really doubt that the average DBA will want
those messages there all the time.
I wonder whether it would be pract
I like the idea of having a autovacuum_log_min_messages. From my
previous experience the pg_autovacuum.log files have been useful in
diagnosing problems in the field.
- Joe
On 11/9/05, Tom Lane <[EMAIL PROTECTED]> wrote:
Joe Maldonado <[EMAIL PROTECTED]> writes:> I agree...for now while I'm devel
Joe Maldonado <[EMAIL PROTECTED]> writes:
> I agree...for now while I'm developing and debugging my application I can
> have the logging be that verbose...I agree that these should be handled as
> info messages, since they are invaluable in investigating problems.
This would be a pretty bad idea I
Joe Maldonado wrote:
I have not seen any information so far on this but is there a way to
get the autovacuum daemon in PostgreSQL 8.1 to log the tables which it
is perfoming vacuum or analyze operation on?
I think the autovacuum daemon does log it's activity however all it's
output is set at
I agree...for now while I'm developing and debugging my application I
can have the logging be that verbose...I agree that these should be
handled as info messages, since they are invaluable in investigating
problems.
- JoeOn 11/9/05, Matthew T. O'Connor <[EMAIL PROTECTED]> wrote:
Joe Maldonado
Hello,
I have not seen any information so far on this but is there a way to
get the autovacuum daemon in PostgreSQL 8.1 to log the tables which it
is perfoming vacuum or analyze operation on?-- Joe Maldonado
16 matches
Mail list logo
