Skip to content

P
Postgres FD Implementation
Commit ee33fe88 authored by Neil Conway's avatar Neil Conway
Browse files
Options

Significant improvements to the documentation for the new cost-based 

vacuum delay feature, including updating the docs for Tom's recent
improvements. There is still more work to be done here: for example,
adding some more information on the practical use of cost-based
vacuum delay to the "maintenance" section would probably be a good
idea.
parent 11acc1ff
Hide whitespace changes
Inline Side-by-side
Showing with 95 additions and 71 deletions
doc/src/sgml/runtime.sgml
View file @ ee33fe88
<!-- <!--
$PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.239 2004/02/17 05:45:17 neilc Exp $ $PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.240 2004/02/17 06:28:05 neilc Exp $
--> -->
<Chapter Id="runtime"> <Chapter Id="runtime">
...@@ -992,83 +992,107 @@ SET ENABLE_SEQSCAN TO OFF; ...@@ -992,83 +992,107 @@ SET ENABLE_SEQSCAN TO OFF;
</sect3> </sect3>
<sect3 id="runtime-config-resource-vacuum-cost"> <sect3 id="runtime-config-resource-vacuum-cost">
<title>Cost Based Vacuum Delay</title> <title>Cost-Based Vacuum Delay</title>
<variablelist> <para>
<varlistentry> During the execution of <command>VACUUM</command>,
<term><varname>vacuum_cost_page_hit</varname> (<type>integer</type>)</term> <command>VACUUM FULL</command> and <command>ANALYZE</command>,
<listitem> the system mantains an internal counter that keeps track of the
<para> cost of the various I/O operations that are performed. When the
During a default <command>VACUUM</command> (not accumulated cost reaches a limit
<command>FULL</command>) the system maintains and internal counter (specified by <varname>vacuum_cost_limit</varname>), the backend performing
accumulating the cost of various operations performed. When the the operation will sleep for a while (specified by
accumulated cost reaches a limit, the backend performing the <varname>vacuum_cost_naptime</varname>). Then it will reset the
<command>VACUUM</command> will sleep for a while, reset the counter and continue execution.
accumulator and continue. The intention is to lower the IO impact </para>
of <command>VACUUM</command>.
</para>
<para> <para>
The variable <varname>vacuum_cost_page_hit</varname> is the cost The intent of this feature is to allow administrators the reduce
for vacuuming a buffer found inside the shared buffer cache. the I/O impact of these commands on concurrent database
It represents the cost to lock the buffer pool, lookup the activity. There are some situations in which it is not very
shared hash table and to actually scan the block content. important that maintainence commands like
</para> <command>VACUUM</command> and <command>ANALYZE</command> finish
</listitem> quickly; however, it is usually very important these these
</varlistentry> commands do not significantly interfere with the ability of the
system to perform other database operations. Cost-based vacuum
delay provides a way for administrators to achieve this.
</para>
<varlistentry> <para>
<term><varname>vacuum_cost_page_miss</varname> (<type>integer</type>)</term> This feature is disabled by default. To enable it, set the
<listitem> <varname>vacuum_cost_naptime</varname> variable to a reasonable
<para> value.
The cost for vacuuming a buffer that has to be read from disk. </para>
This represents the effort to lock the buffer pool, lookup the
cache directory, reading the block from disk and scanning the
content.
</para>
</listitem>
</varlistentry>
<varlistentry> <variablelist>
<term><varname>vacuum_cost_page_dirty</varname> (<type>integer</type>)</term> <varlistentry>
<listitem> <term><varname>vacuum_cost_page_hit</varname> (<type>integer</type>)</term>
<para> <listitem>
This extra cost is added when vacuum modifies a block that was <para>
clean before. It represents the extra IO required to flush the The cost for vacuuming a buffer found in the shared buffer
dirty block out to disk again. cache. It represents the cost to lock the buffer pool, lookup
</para> the shared hash table and scan the content of the page. The
</listitem> default value is 1.
</varlistentry> </para>
</listitem>
</varlistentry>
<varlistentry> <varlistentry>
<term><varname>vacuum_cost_limit</varname> (<type>integer</type>)</term> <term><varname>vacuum_cost_page_miss</varname> (<type>integer</type>)</term>
<listitem> <listitem>
<para> <para>
This is the cost limit that must be reached or exceeded before The cost for vacuuming a buffer that has to be read from
the <command>VACUUM</command> will nap. disk. This represents the effort to lock the buffer pool,
</para> lookup the shared hash table, read the desired block in from
</listitem> the disk and scan its content. The default value is 10.
</varlistentry> </para>
</listitem>
</varlistentry>
<varlistentry> <varlistentry>
<term><varname>vacuum_cost_naptime</varname> (<type>integer</type>)</term> <term><varname>vacuum_cost_page_dirty</varname> (<type>integer</type>)</term>
<listitem> <listitem>
<para> <para>
The time im milliseconds the <command>VACUUM</command> will The extra cost added when vacuum modifies a block that was
nap when the cost limit has been reached or exceeded. previously clean. It represents the extra I/O required to
There are certain bulk operations that hold critical flush the dirty block out to disk again. The default value is
locks and should therefore perform 20.
as quickly as possible. Because of that it is possible that the </para>
cost actually accumulates far higher than this limit. To compensate </listitem>
for this, the final naptime is calculated as </varlistentry>
<varname>vacuum_cost_naptime</varname> *
<varname>accumulated_balance</varname> / <varlistentry>
<varname>vacuum_cost_limit</varname> with a maximum of <term><varname>vacuum_cost_limit</varname> (<type>integer</type>)</term>
<varname>vacuum_cost_naptime</varname> * 4. <listitem>
</para> <para>
</listitem> The accumulated cost that will cause the backend to briefly
</varlistentry> nap. The default value is 200.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>vacuum_cost_naptime</varname> (<type>integer</type>)</term>
<listitem>
<para>
The length of time in milliseconds that a backend will nap
when the cost limit has been exceeded. There are certain bulk
operations that hold critical locks and should therefore
complete as quickly as possible. Because of that it is
possible that the cost actually accumulates far higher than
this limit. To compensate for this, the final naptime is
calculated as <varname>vacuum_cost_naptime</varname> *
<varname>accumulated_balance</varname> /
<varname>vacuum_cost_limit</varname> with a maximum of
<varname>vacuum_cost_naptime</varname> * 4.
</para>
<para>
The default value is 0, which disables the cost-based vacuum
delay feature.
</para>
</listitem>
</varlistentry>
</variablelist> </variablelist>
</sect3> </sect3>
</sect2> </sect2>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment