Attached patch takes a swing at improving the autovacuum wording in 
maintenance.sgml. 

On a related note I was thinking to add a note in the runtime config section 
for autovacuum_enabled that stats_start_collector and stats_row_level must be 
on for enabled to work, would that still go in runtime.sgml ?

On a related note to that, I am wondering if it might be better to have the 
postmaster issue a fatal error on startup if autovacuum is on and stats are 
off, rather than the warning it does now. ISTM it is very easy to miss that 
warning (since it is only sent to stderr and not stout afaict) and looking in 
pg_settings there would be no indication that anything was wrong, other than 
autovacuum being set to off (perhaps if it was set to 'error, stats disabled' 
or some such it might be better?)

-- 
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Index: maintenance.sgml
===================================================================
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v
retrieving revision 1.46
diff -c -r1.46 maintenance.sgml
*** maintenance.sgml	13 Sep 2005 01:51:18 -0000	1.46
--- maintenance.sgml	16 Sep 2005 04:03:41 -0000
***************
*** 180,186 ****
      rate of data modification <command>VACUUM</command> busy tables as
      often as once every few minutes.)  If you have multiple databases
      in a cluster, don't forget to <command>VACUUM</command> each one;
!     the program <filename>vacuumdb</> may be helpful.
     </para>
  
     <para>
--- 180,187 ----
      rate of data modification <command>VACUUM</command> busy tables as
      often as once every few minutes.)  If you have multiple databases
      in a cluster, don't forget to <command>VACUUM</command> each one;
!     the program <xref linkend="app-vacuumdb" endterm="app-vacuumdb-title">
!     may be helpful.
     </para>
  
     <para>
***************
*** 466,472 ****
     <para>
      Beginning in <productname>PostgreSQL </productname> 8.1, there is a
      separate optional server process called the <firstterm>autovacuum
!     daemon</firstterm>, whose purpose is to automate the issuance of
      <command>VACUUM</command> and <command>ANALYZE </command> commands.
      When enabled, the autovacuum daemon runs periodically and checks for
      tables that have had a large number of inserted, updated or deleted
--- 467,473 ----
     <para>
      Beginning in <productname>PostgreSQL </productname> 8.1, there is a
      separate optional server process called the <firstterm>autovacuum
!     daemon</firstterm>, whose purpose is to automate the execution of
      <command>VACUUM</command> and <command>ANALYZE </command> commands.
      When enabled, the autovacuum daemon runs periodically and checks for
      tables that have had a large number of inserted, updated or deleted
***************
*** 521,549 ****
  
     <para>
      Note that if any of the values in <structname>pg_autovacuum</structname>
!     is set to a negative number, or if a tuple is not present at all in
      <structname>pg_autovacuum</structname> for any particular table, the
      equivalent value from <filename>postgresql.conf</filename> is used.
     </para>
  
     <para>
      Besides the base threshold values and scale factors, there are three
!     parameters that can be set for each table in <structname>pg_autovacuum</structname>: 
!     the vacuum cost delay
      (<structname>pg_autovacuum</structname>.<structfield>vac_cost_delay</structfield>)
      and the vacuum cost limit
!     (<structname>pg_autovacuum</structname>.<structfield>vac_cost_limit</structfield>).
!     They are used to set table-specific values for the
      <xref linkend="runtime-config-resource-vacuum-cost" endterm="runtime-config-resource-vacuum-cost-title">
      feature.  The above note about negative values also applies here, but
      also note that if the <filename>postgresql.conf</filename> variables
      <varname>autovacuum_vacuum_cost_limit</varname> and
      <varname>autovacuum_vacuum_cost_delay</varname> are also set to negative 
!     values, the <varname>vacuum_cost_limit</varname> and
      <varname>vacuum_cost_delay</varname> values will be used instead.
-     The other parameter, <structname>pg_autovacuum</>.<structfield>enabled</>,
- 	can be used to instruct the autovacuum daemon to skip any particular table
- 	by setting it to <literal>false</literal>.
     </para>
  
    </sect2>
--- 522,550 ----
  
     <para>
      Note that if any of the values in <structname>pg_autovacuum</structname>
!     are set to a negative number, or if a tuple is not present at all in
      <structname>pg_autovacuum</structname> for any particular table, the
      equivalent value from <filename>postgresql.conf</filename> is used.
     </para>
  
     <para>
      Besides the base threshold values and scale factors, there are three
!     parameters that can be set for each table in <structname>pg_autovacuum</structname>. 
!     The first parameter, <structname>pg_autovacuum</>.<structfield>enabled</>,
! 	can be used to instruct the autovacuum daemon to skip any particular table
! 	by setting it to <literal>false</literal>.
!     The other two, the vacuum cost delay
      (<structname>pg_autovacuum</structname>.<structfield>vac_cost_delay</structfield>)
      and the vacuum cost limit
!     (<structname>pg_autovacuum</structname>.<structfield>vac_cost_limit</structfield>), 
!     are used to set table-specific values for the
      <xref linkend="runtime-config-resource-vacuum-cost" endterm="runtime-config-resource-vacuum-cost-title">
      feature.  The above note about negative values also applies here, but
      also note that if the <filename>postgresql.conf</filename> variables
      <varname>autovacuum_vacuum_cost_limit</varname> and
      <varname>autovacuum_vacuum_cost_delay</varname> are also set to negative 
!     values, the global <varname>vacuum_cost_limit</varname> and
      <varname>vacuum_cost_delay</varname> values will be used instead.
     </para>
  
    </sect2>
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faq

Reply via email to