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

Re: VACUUM vs auto-vacuum daemon

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Sabin Coanda <sabin(dot)coanda(at)deuromedia(dot)ro>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: VACUUM vs auto-vacuum daemon
Date: 2007-06-12 16:08:02
Message-ID: 20070612160802.GC15517@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-performance
Sabin Coanda wrote:
> Hi there,
> 
> Using explicitly VACUUM command give me the opportunity to fine tune my 
> VACUUM scheduling parameters, after I analyze the log generated by VACUUM 
> VERBOSE.
> 
> On the other hand I'd like to use the auto-vacuum mechanism because of its 
> facilities. Unfortunately, after I made some initial estimations for 
> autovacuum_naptime, and I set the specific data into pg_autovacuum table, I 
> have not a feedback from the auto-vacuum mechanism to check that it works 
> well or not.  It would be nice to have some kind of log similar with the one 
> generated by VACUUM VERBOSE. Is the auto-vacuum mechanism able to provide 
> such a useful log ?

No, sorry, autovacuum is not currently very good regarding reporting its
activities.  It's a lot better in 8.3 but even there it doesn't report
the full VACUUM VERBOSE log.  It looks like this:

LOG:  automatic vacuum of table "alvherre.public.foo": index scans: 0
        pages: 45 removed, 0 remain
        tuples: 10000 removed, 0 remain
        system usage: CPU 0.00s/0.00u sec elapsed 0.01 sec
LOG:  automatic analyze of table "alvherre.public.foo" system usage: CPU 0.00s/0.00u sec elapsed 0.00 sec

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

In response to

pgsql-performance by date

Next:From: Tom LaneDate: 2007-06-12 16:09:46
Subject: Re: test / live environment, major performance difference
Previous:From: Tyrrill, EdDate: 2007-06-12 15:56:24
Subject: Re: Best way to delete unreferenced rows?

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