head	1.15;
access;
symbols
	REL7_4_29:1.5.2.1
	REL8_0_25:1.11.4.2
	REL7_4_28:1.5.2.1
	REL8_0_24:1.11.4.2
	REL7_4_27:1.5.2.1
	REL8_0_23:1.11.4.2
	REL7_4_26:1.5.2.1
	REL8_0_22:1.11.4.2
	REL7_4_25:1.5.2.1
	REL8_0_21:1.11.4.2
	REL7_4_24:1.5.2.1
	REL8_0_20:1.11.4.2
	REL7_4_23:1.5.2.1
	REL8_0_19:1.11.4.2
	REL7_4_22:1.5.2.1
	REL8_0_18:1.11.4.2
	REL7_4_21:1.5.2.1
	REL8_0_17:1.11.4.2
	REL7_4_20:1.5.2.1
	REL8_0_16:1.11.4.2
	REL7_4_19:1.5.2.1
	REL8_0_15:1.11.4.2
	REL7_4_18:1.5.2.1
	REL8_0_14:1.11.4.2
	REL7_4_17:1.5.2.1
	REL8_0_13:1.11.4.2
	REL8_0_12:1.11.4.2
	REL7_4_16:1.5.2.1
	REL8_0_11:1.11.4.2
	REL8_0_10:1.11.4.2
	REL7_4_15:1.5.2.1
	REL8_0_9:1.11.4.2
	REL7_4_14:1.5.2.1
	REL7_4_13:1.5.2.1
	REL8_0_8:1.11.4.2
	REL7_4_12:1.5.2.1
	REL8_0_7:1.11.4.2
	REL7_4_11:1.5.2.1
	REL8_0_6:1.11.4.2
	REL7_4_10:1.5.2.1
	REL8_0_5:1.11.4.2
	REL7_4_9:1.5.2.1
	REL8_0_4:1.11.4.2
	REL7_4_8:1.5.2.1
	REL8_0_3:1.11.4.2
	REL8_0_2:1.11.4.2
	REL7_4_7:1.5.2.1
	REL8_0_1:1.11.4.1
	REL8_0_STABLE:1.11.0.4
	REL8_0_0:1.11.0.2
	REL8_0_0RC5:1.11
	REL8_0_0RC4:1.11
	REL8_0_0RC3:1.11
	REL8_0_0RC2:1.11
	REL8_0_0RC1:1.11
	REL8_0_0BETA5:1.10
	REL8_0_0BETA4:1.8
	REL7_4_6:1.5.2.1
	REL8_0_0BETA3:1.8
	REL8_0_0BETA2:1.7
	REL7_4_5:1.5.2.1
	REL7_4_4:1.5.2.1
	REL8_0_0BETA1:1.7
	REL7_4_3:1.5.2.1
	REL7_4_2:1.5.2.1
	REL7_4_1:1.5.2.1
	REL7_4:1.5.2.1
	REL7_4_RC2:1.5.2.1
	REL7_4_STABLE:1.5.0.2
	REL7_4_RC1:1.5
	REL7_4_BETA5:1.5
	REL7_4_BETA4:1.3
	REL7_4_BETA3:1.3
	REL7_4_BETA2:1.2
	WIN32_DEV:1.2.0.2
	REL7_4_BETA1:1.2;
locks; strict;
comment	@# @;


1.15
date	2005.07.29.19.38.22;	author tgl;	state dead;
branches;
next	1.14;

1.14
date	2005.04.19.03.35.15;	author momjian;	state Exp;
branches;
next	1.13;

1.13
date	2005.03.30.05.05.01;	author neilc;	state Exp;
branches;
next	1.12;

1.12
date	2005.01.24.00.17.33;	author neilc;	state Exp;
branches;
next	1.11;

1.11
date	2004.12.02.22.48.10;	author momjian;	state Exp;
branches
	1.11.4.1;
next	1.10;

1.10
date	2004.11.17.21.30.36;	author tgl;	state Exp;
branches;
next	1.9;

1.9
date	2004.11.17.16.54.15;	author tgl;	state Exp;
branches;
next	1.8;

1.8
date	2004.09.14.04.06.20;	author tgl;	state Exp;
branches;
next	1.7;

1.7
date	2004.04.19.21.30.18;	author momjian;	state Exp;
branches;
next	1.6;

1.6
date	2003.11.09.03.15.46;	author momjian;	state Exp;
branches;
next	1.5;

1.5
date	2003.10.16.03.47.28;	author momjian;	state Exp;
branches
	1.5.2.1;
next	1.4;

1.4
date	2003.10.08.18.18.04;	author momjian;	state Exp;
branches;
next	1.3;

1.3
date	2003.09.13.16.26.17;	author momjian;	state Exp;
branches;
next	1.2;

1.2
date	2003.06.12.01.36.44;	author momjian;	state Exp;
branches;
next	1.1;

1.1
date	2003.03.23.20.16.06;	author momjian;	state Exp;
branches;
next	;

1.5.2.1
date	2003.11.09.03.17.37;	author momjian;	state Exp;
branches;
next	;

1.11.4.1
date	2005.01.26.22.25.23;	author tgl;	state Exp;
branches;
next	1.11.4.2;

1.11.4.2
date	2005.03.30.05.06.32;	author neilc;	state Exp;
branches;
next	;


desc
@@


1.15
log
@Remove contrib version of pg_autovacuum --- superseded by integrated
version.
@
text
@pg_autovacuum README
--------------------

pg_autovacuum is a libpq client program that monitors all the
databases associated with a PostgreSQL server.  It uses the statistics
collector to monitor insert, update and delete activity.  

When a table exceeds a insert or delete threshold (for more detail on
thresholds, see "Vacuum and Analyze" below) then that table will be
vacuumed and/or analyzed.

This allows PostgreSQL to keep the FSM (Free Space Map) and table
statistics up to date, and eliminates the need to schedule periodic
vacuums.

The primary benefit of pg_autovacuum is that the FSM and table
statistic information are updated more nearly as frequently as needed.
When a table is actively changing, pg_autovacuum will perform the
VACUUMs and ANALYZEs that such a table needs, whereas if a table
remains static, no cycles will be wasted performing this
unnecessarily.

A secondary benefit of pg_autovacuum is that it ensures that a
database wide vacuum is performed prior to XID wraparound.  This is an
important, if rare, problem, as failing to do so can result in major
data loss.  (See the section in the _Administrator's Guide_ entitled
"Preventing transaction ID wraparound failures" for more details.)

KNOWN ISSUES:
-------------

pg_autovacuum has been tested under Redhat Linux (by me) and Debian
GNU/Linux, Solaris, and AIX (by Christopher B. Browne) and all known
bugs have been resolved.  Please report any problems to the hackers
list.

pg_autovacuum requires that the statistics system be enabled and
reporting row level stats.  The overhead of the stats system has been
shown to be significant under certain workloads.  For instance, a
tight loop of queries performing "select 1" was found to run nearly
30% slower when row-level stats were enabled.  However, in practice,
with more realistic workloads, the stats system overhead is usually
nominal.

pg_autovacuum does not get started automatically by either the
postmaster or by pg_ctl.  Similarly, when the postmaster exits, no one
tells pg_autovacuum.  The result of that is that at the start of the
next loop, pg_autovacuum will fail to connect to the server and
exit().  Any time it fails to connect pg_autovacuum exit()s.

While pg_autovacuum can manage vacuums for as many databases as you
may have tied to a particular PostgreSQL postmaster, it can only
connect to a single PostgreSQL postmaster.  Thus, if you have multiple
postmasters on a particular host, you will need multiple pg_autovacuum
instances, and they have no way, at present, to coordinate between one
another to ensure that they do not concurrently vacuum big tables.

When installed as a service under Windows, there is currently no way to
know the name of the PostgreSQL server service (if there even is one)
so it is not possible to specify a startup dependency. It is therefore
possible for pg_autovacuum to start before the server.

When installed as a service under Windows, if the -P option is used to
specify the connection password, this option (and the password) is 
stored in plain text in the registry.

TODO:
-----

At present, there are no sample scripts to automatically start up
pg_autovacuum along with the database.  It would be desirable to have
a SysV script to start up pg_autovacuum after PostgreSQL has been
started.

Some users have expressed interest in making pg_autovacuum more
configurable so that certain tables known to be inactive could be
excluded from being vacuumed.  It would probably make sense to
introduce this sort of functionality by providing arguments to specify
the database and schema in which to find a configuration table.

It would also be desirable for the daemon to monitor how busy the
system is, with a view to deferring vacuums until there is less other
activity.

INSTALL:
--------

As of postgresql v7.4 pg_autovacuum is included in the main source
tree under contrib.  Therefore you merely need to "make && make
install" (similar to most other contrib modules) and it will be
installed for you.

If you are using an earlier version of PostgreSQL, uncompress the
tar.gz file into the contrib directory and modify the contrib/Makefile
to include the pg_autovacuum directory.  pg_autovacuum will then be
built as part of the standard postgresql install.  It is known to work
with v7.3 releases; it is not presently compatible with v7.2.

make sure that the following are set in postgresql.conf:

  stats_start_collector = true
  stats_row_level = true

Start up the postmaster, then execute the pg_autovacuum executable.

If you have a script that automatically starts up the PostgreSQL
instance, you might add in, after that, something similar to the
following:

  sleep 10    # To give the database some time to start up
  $PGBINS/pg_autovacuum -D -s $SBASE -S $SSCALE ... [other arguments]

Command line arguments:
-----------------------

pg_autovacuum has the following optional arguments:

-d debug: 0 silent, 1 basic info, 2 more debug info,  etc...
-D daemonize: Detach from tty and run in background.
-s sleep base value: see "Sleeping" below.
-S sleep scaling factor: see "Sleeping" below.
-v vacuum base threshold: see "Vacuum and Analyze" below.
-V vacuum scaling factor: see "Vacuum and Analyze" below.
-a analyze base threshold: see "Vacuum and Analyze" below.
-A analyze scaling factor: see "Vacuum and Analyze" below.
-i update interval: how often (in terms of iterations of the primary loop
   over the database list) to update the database list. The default is 2,
   which means the list will be updated before every other pass through
   the database list.
-L log file: Name of file to which output is submitted, otherwise STDERR
-U username: Username pg_autovacuum will use to connect with, if not
   specified the current username is used.
-P password: Password pg_autovacuum will use to connect with. *WARNING*
   This option is insecure. When installed as a Windows Service, this
   option will be stored in plain text in the registry. When used with
   most Unix variants, other users will be able to see the argument to
   the "-P" option via ps(1). The ~/.pgpass file can be used to
   specify a password more securely.
-H host: host name or IP to connect to.
-p port: port used for connection.
-h help: list of command line options.

The following 5 autovacuum command line options correspond to the various
cost-based vacuum settings.  If not given, then the cluster default values
will be used.

-c	vacuum_cost_delay
-C	vacuum_cost_page_hit
-m	vacuum_cost_page_miss
-n	vacuum_cost_page_dirty
-l	vacuum_cost_limit


Numerous arguments have default values defined in pg_autovacuum.h.  At
the time of writing they are:

-d 1
-v 1000
-V 2   
-a 500 (half of -v if not specified)
-A 1   (half of -V if not specified)
-s 300 (5 minutes)
-S 2
-i 2

The following arguments are used on Windows only:

-I Install the executable as a Windows service. Other appropriate command
   line options will be stored in the registry and passed to the service 
   at startup. *WARNING* This includes the connection password which will 
   be stored in plain text.
	     
-N service user: Name of the Windows user account under which the service
   will run. Only used when installing as a Windows service.
   
-W service password: The password for the service account. Only used when 
   installing as a Windows service.

-R Uninstall pg_autovacuum as a service.

-E Dependent service that must start before this service. Normally this will be
   a PostgreSQL instance, e.g. "-E pgsql-8.0.0". Only used when installing as 
   a Windows service.

Vacuum and Analyze:
-------------------

pg_autovacuum performs either a VACUUM ANALYZE or just ANALYZE
depending on the mixture of table activity (insert, update, or
delete):

- If the number of (inserts + updates + deletes) > AnalyzeThreshold, then
  only an analyze is performed.

- If the number of (deletes + updates) > VacuumThreshold, then a
  vacuum analyze is performed.

VacuumThreshold is equal to:
    vacuum_base_value + (vacuum_scaling_factor * "number of tuples in the table")

AnalyzeThreshold is equal to:
    analyze_base_value + (analyze_scaling_factor * "number of tuples in the table")

The AnalyzeThreshold defaults to half of the VacuumThreshold since it
represents a much less expensive operation (approx 5%-10% of vacuum),
and running ANALYZE more often should not substantially degrade system
performance.

Sleeping:
---------

pg_autovacuum sleeps for a while after it is done checking all the
databases.  It does this in order to limit the amount of system
resources it consumes.  This allows the system administrator to
configure pg_autovacuum to be more or less aggressive.

Reducing the sleep time will cause pg_autovacuum to respond more
quickly to changes, whether they be database addition/removal, table
addition/removal, or just normal table activity.

On the other hand, setting pg_autovacuum to sleep values too
aggressively (to too short periods of time) can have a negative effect
on server performance.  For instance, if a table gets vacuumed 5 times
during the course of a large set of updates, this is likely to take a
lot more work than if the table was vacuumed just once, at the end.

The total time it sleeps is equal to:

  base_sleep_value + sleep_scaling_factor * "duration of the previous
  loop"

Note that timing measurements are made in seconds; specifying
"pg_vacuum -s 1" means pg_autovacuum could poll the database up to 60
times minute.  In a system with large tables where vacuums may run for
several minutes, rather longer times between vacuums are likely to be
appropriate.

What pg_autovacuum monitors:
----------------------------

pg_autovacuum dynamically generates a list of all databases and tables
that exist on the server.  It will dynamically add and remove
databases and tables that are removed from the database server while
pg_autovacuum is running.  Overhead is fairly small per object.  For
example: 10 databases with 10 tables each appears to less than 10k of
memory on my Linux box.
@


1.14
log
@The following patch should allow UPDATE_INTERVAL to be specified on the
command line. We find this useful because we frequently deal with
thousands of tables in an environment where neither the databases nor
the tables are updated frequently. This helps allow us to cut down on
the overhead of updating the list for every other primary loop of
pg_autovacuum.

I chose -i as the command-line argument and documented it briefly in
the README.

The patch was applied to the 7.4.7 version of pg_autovacuum in contrib.

Thomas F.O'Connell
@
text
@@


1.13
log
@Document that the "-P" option to pg_autovacuum is insecure on many
platforms, and suggest using ~/.pgpass instead.
@
text
@d126 4
d164 1
@


1.12
log
@Fix typo.
@
text
@d39 3
a41 3
shown to have a significant cost under certain workloads.  For
instance, a tight loop of queries performing "select 1" was found to
run nearly 30% slower when stats were enabled.  However, in practice,
d130 5
a134 2
   When installed as a Windows Service, this option will be stored in plain
   text in the registry.
@


1.11
log
@> > 8.0beta3 has pg_autovacuum included, when I want to run this as a
> > Windows service, it says you can use the -I and -R options.
> >
> > When I do that and I specify a password with '-P'
> (uppercase) then in
> > the registry it's saved as '-p' (lowercase) in the
> service-commandline
> > (ImagePath).

This was fixed in v1.21 of pg_autovacuum.c, That rev is tagged for
beta3, so you should not be seeing this issue unless you actually have
an older version for some reason.

http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/pg_autovacuum/p
g_autovacuum.c.diff?r1=1.20;r2=1.21;f=h

> > Also it removes the quotes I added and I'm not so sure it
> would work
> > the way it's supposed to, without it.

It's not so much that it strips them (that happens automagically), more
that it doesn't re-add them when it writes the command line in the
registry. The attached patch fixes that by simply quoting all options
that may need it.
> > If you add DependOnService (a REG_MULTI_SZ an
> array-like-thingie) and
> > have the name (in this case: pgsql-8.0-beta2-dev3) of a service it
> > depends on, it will not fail to start (it will not even try, as
> > PostgreSQL is not running), when PostgreSQL already failed.
> >
> > Maybe it's an idea to specify it on the commandline (what
> service to
> > depend on).

A -E <service> option is added in the attached patch.

Dave Page
@
text
@d168 1
a168 1
-W service password: The password for the service account.Only used when 
@


1.11.4.1
log
@Adjust Windows autovacuum service to retry for up to 5 minutes waiting
for the postmaster to start.  Dave Page
@
text
@d168 1
a168 1
-W service password: The password for the service account. Only used when 
@


1.11.4.2
log
@Document that the "-P" option to pg_autovacuum is insecure on many
platforms, and suggest using ~/.pgpass instead.
@
text
@d39 3
a41 3
shown to be significant under certain workloads.  For instance, a
tight loop of queries performing "select 1" was found to run nearly
30% slower when row-level stats were enabled.  However, in practice,
d130 2
a131 5
   This option is insecure. When installed as a Windows Service, this
   option will be stored in plain text in the registry. When used with
   most Unix variants, other users will be able to see the argument to
   the "-P" option via ps(1). The ~/.pgpass file can be used to
   specify a password more securely.
@


1.10
log
@Rename vacuum_cost_limit switch from -N to -l to avoid conflict with
existing Windows-only switch.
@
text
@d166 1
a166 1
   will run.
d168 2
a169 1
-W service password: The password for the service account.
d173 4
@


1.9
log
@Add options to pg_autovacuum to support setting the cost-based-vacuum
parameters differently from their default values.  Matthew T. O'Connor
@
text
@d144 1
a144 1
-N	vacuum_cost_limit
@


1.8
log
@Fix some minor issues with the new Win32 service code for autovacuum,
and add documentation.  Dave Page
@
text
@d136 11
@


1.7
log
@The attached patch for contrib/pg_autovacuum/README.pg_autovacuum fixes
one apparent error and makes a minor stylistic change that makes it more
consistent and makes clear something that confused me :-)

Andrew Dunstan
@
text
@d58 9
d129 3
a131 1
-P password: Password pg_autovacuum will use to connect with.
d147 13
@


1.6
log
@Fix typo on autovacuum readme.
@
text
@d113 4
a116 4
-v vacuum base threshold: see Vacuum and Analyze.
-V vacuum scaling factor: see Vacuum and Analyze.
-a analyze base threshold: see Vacuum and Analyze.
-A analyze scaling factor: see Vacuum and Analyze.
d132 1
a132 1
-A 1   (half of -v if not specified)
@


1.5
log
@I have run pg_autovacuum on AIX, so that can, at least loosely, be
considered "tested."

And I have turned all of the 7.4 HISTORY material into DocBook for
release.sgml

Christopher Browne
@
text
@d150 1
a150 1
deleteThreshold is equal to: 
d153 1
a153 1
insertThreshold is equal to: 
@


1.5.2.1
log
@Fix typo on autovacuum readme.
@
text
@d150 1
a150 1
VacuumThreshold is equal to:
d153 1
a153 1
AnalyzeThreshold is equal to:
@


1.4
log
@Change some awkward wording in the pg_autovacuum README file. I really
only read this because of Niel :-)

Robert Treat
@
text
@d33 3
a35 2
GNU/Linux and Solaris (by Christopher B. Browne) and all known bugs
have been resolved.  Please report any problems to the hackers list.
d39 5
a43 4
shown to have a significant cost under certain workloads.  For instance,
a tight loop of queries performing "select 1" was found to run nearly
30% slower when stats were enabled.  However, in practice, with more
realistic workloads, the stats system overhead is usually nominal.
d72 4
d87 2
a88 1
built as part of the standard postgresql install.
@


1.3
log
@> OK, well as we wait on the fix for the stats system, let me submit my
> patch for pg_autovacuum.  This patch assumes that the stats system will
> be fixed so that all inserts, updates and deletes performed on shared
> tables reguardless of what database those commands were executed from,
> will show up in the stats shown in each database.

I had to make a further change to this to take quotes off the 'last
ANALYZE' in order for it to not overquote the relation name, so
there's a _little_ work left to get it to play well.

I have deployed it onto several boxes that should be doing some
vacuuming over the weekend, and it is now certainly hitting pg_
tables.

I would like to present a CVS-oriented patch; unfortunately, I had to
change the indentation patterns when editing some of it :-(.  The
following _may_ be good; not sure...

Matthew T. O'Connor
Christopher Browne
@
text
@d38 1
a38 1
shown to be significant costly under certain workloads.  For instance,
@


1.2
log
@This patch updates pg_autovacuum in several ways:
* A few bug fixes
* fixes solaris compile and crash issue
* decouple vacuum analyze and analyze thresholds
* detach from tty (dameonize)
* improved logging layout
* more conservative default configuration
* improved, expanded and updated README

please apply and 1st convenience, or before code freeze which ever comes
first :-)

At this point I think I have brought pg_autovacuum and its client side
design as far as I think it should go.  It works, keeping file sizes in
check, helps performance and give the administrator a fair amount
flexibility in configuring it.

Next up is to do the FSM based design that is integrated into the back
end.

p.s. Thanks to Christopher Browne for his help.

Matthew T. O'Connor
@
text
@d5 1
a5 1
databases associated with a postgresql server.  It uses the stats
d8 7
a14 5
When a table exceeds its insert or delete threshold (more detail
on thresholds below) then that table will be  vacuumed or analyzed.  

This allows postgresql to keep the fsm and table statistics up to
date, and eliminates the need to schedule periodic vacuums.
d17 5
a21 4
statistic information are updated as needed.  When a table is actively
changing, pg_autovacuum will perform the necessary vacuums and
analyzes, whereas if a table remains static, no cycles will be wasted
performing unnecessary vacuums/analyzes.
d24 1
a24 1
database wide vacuum is performed prior to xid wraparound.  This is an
d26 2
a27 2
data loss.

a30 16
pg_autovacuum has been tested under Redhat Linux (by me) and Solaris (by
Christopher B. Browne) and all known bugs have been resolved.  Please report
any problems to the hackers list.

pg_autovacuum does not get started automatically by either the postmaster or
by pg_ctl.  Along the sames lines, when the postmaster exits no one tells
pg_autovacuum.  The result is that at the start of the next loop,
pg_autovacuum fails to connect to the server and exits.  Any time  it fails
to connect pg_autovacuum exits.

pg_autovacuum requires that the stats system be enabled and reporting row
level stats.  The overhead of the stats system has been shown to be
significant under certain workloads.  For instance a tight loop of queries
performing "select 1" was nearly 30% slower with stats enabled.  However,
in practice with more realistic workloads, the stats system overhead is
usually nominal.
d32 37
d73 9
a81 8
As of postgresql v7.4 pg_autovacuum is included in the main source tree
under contrib.  Therefore you just make && make install (similar to most other
contrib modules) and it will be installed for you.

If you are using an earlier version of postgresql just uncompress the tar.gz
into the contrib directory and modify the contrib/Makefile to include the pg_autovacuum
directory.  pg_autovacuum will then be made as part of the standard
postgresql install.
d83 1
a83 1
make sure that the folowing are set in postgresql.conf
d88 5
a92 1
start up the postmaster, then execute the pg_autovacuum executable.
d94 2
d103 1
a103 1
-D dameonize: Detach from tty and run in background.
d114 1
a114 1
-H host: host name or IP to connect too.
d118 2
a119 2
All arguments have default values defined in pg_autovacuum.h.  At the
time of writing they are:
d124 2
a125 2
-a 500 (half of -v is not specified)
-A 1   (half of -v is not specified)
d133 3
a135 2
pg_autovacuum performs either a vacuum analyze or just analyze depending
on the quantity and type of table activity (insert, update, or delete):
d140 1
a140 1
- If the number of (deletes + updates ) > VacuumThreshold, then a
d150 3
a152 2
represents a much less expensive operation (approx 5%-10% of vacuum), and
running it more often should not substantially degrade system performance.
d159 1
a159 1
resources it consumes.  This also allows the system administrator to
d166 5
a170 5
On the other hand, setting pg_autovaccum to sleep values to agressivly
(for too short a period of time) can have a negative effect on server
performance.  If a table gets vacuumed 5 times during the course of a
large update, this is likely to take much longer than if the table was
vacuumed only once, at the end.
d178 4
a181 3
"pg_vacuum -s 1" means pg_autovacuum could poll the database upto 60 times
minute.  In a system with large tables where vacuums may run for several
minutes, longer times between vacuums are likely to be appropriate.
d186 6
a191 5
pg_autovacuum dynamically generates a list of all databases and tables that
exist on the server.  It will dynamically add and remove databases and
tables that are removed from the database server while pg_autovacuum is
running.  Overhead is fairly small per object.  For example: 10 databases
with 10 tables each appears to less than 10k of memory on my Linux box.
@


1.1
log
@Rename README in autovacuum code to match Makefile.
@
text
@d2 42
a44 15
pg_autovacuum is a libpq client program that monitors all the databases of a
postgresql server.  It uses the stats collector to monitor insert, update and
delete activity.  When an individual table exceeds it's insert or delete
threshold (more detail on thresholds below) then that table is vacuumed or
analyzed.  This allows postgresql to keep the fsm and table statistics up to
date without having to schedule periodic vacuums with cron regardless of need.

The primary benefit of pg_autovacuum is that the FSM and table statistic information
are updated as needed.  When a table is actively changed pg_autovacuum performs the
necessary vacuums and analyzes, when a table is inactive, no cycles are wasted
performing vacuums and analyzes that are not needed.

A secondary benefit of pg_autovacuum is that it guarantees that a database wide
vacuum is performed prior to xid wraparound.  This is important as failing to do
so can result in major data loss.
d47 10
a56 3
To use pg_autovacuum, uncompress the tar.gz into the contrib directory and modify the
contrib/Makefile to include the pg_autovacuum directory.  pg_autovacuum will then be made as
part of the standard postgresql install.
a58 2
stats_start_collector = true
stats_row_level = true
d60 4
a63 2
start up the postmaster
then, just execute the pg_autovacuum executable.
d67 2
d70 1
d72 1
d75 7
a81 4
-t tuple base threshold: see Vacuuming.
-T tuple scaling factor: see Vacuuming.
-U username: Username pg_autovacuum will use to connect with, if not specified the
   current username is used
d87 10
a96 8
All arguments have default values defined in pg_autovacuum.h.  At the time of this
writing they are:
#define AUTOVACUUM_DEBUG    1
#define BASETHRESHOLD       100
#define SCALINGFACTOR       2
#define SLEEPVALUE          3
#define SLEEPSCALINGFACTOR  2
#define UPDATE_INTERVAL     2
d100 20
a119 7
pg_autovacuum performes either a vacuums analyze or just analyze depending on the table activity.
If the number of (inserts + updates) > insertThreshold, then an only an analyze is performed.
If the number of (deletes + updates ) > deleteThreshold, then a vacuum analyze is performed.
deleteThreshold is equal to: tuple_base_value + (tuple_scaling_factor * "number of tuples in the table")
insertThreshold is equal to: 0.5 * tuple_base_value + (tuple_scaling_factor * "number of tuples in the table")
The insertThreshold is half the deleteThreshold because it's a much lighter operation (approx 5%-10% of vacuum),
so running it more often costs us little in performance degredation.
d122 17
a138 8
pg_autovacuum sleeps after it is done checking all the databases.  It does this so as
to limit the amount of system resources it consumes.  This also allows the system
administrator to configure pg_autovacuum to be more or less aggressive.  Reducing the
sleep time will cause pg_autovacuum to respond more quickly to changes, be they database
addition / removal, table addition / removal, or just normal table activity.  However,
setting these values to high can have a negative net effect on the server.  If a table
gets vacuumed 5 times during the course of a large update, it might take much longer
than if it was vacuumed only once.
a139 1
base_sleep_value + sleep_scaling_factor * "duration of the previous loop"
d141 16
a156 4
What it monitors:
pg_autovacuum dynamically generates a list of databases and tables to monitor, in
addition it will dynamically add and remove databases and tables that are
removed from the database server while pg_autovacuum is running.
@

