config.sgml

来自「PostgreSQL 8.1.4的源码 适用于Linux下的开源数据库系统」· SGML 代码 · 共 1,536 行 · 第 1/5 页

        This variable specifies one or more shared libraries that are
        to be preloaded at server start. A parameterless
        initialization function can optionally be called for each
        library.  To specify that, add a colon and the name of the
        initialization function after the library name. For example
        <literal>'$libdir/mylib:mylib_init'</literal> would cause
        <literal>mylib</> to be preloaded and <literal>mylib_init</>
        to be executed. If more than one library is to be loaded,
        separate their names with commas.
       </para>

       <para>
        If a specified library or initialization function is not found,
        the server will fail to start.
       </para>

       <para>
        <productname>PostgreSQL</productname> procedural language
        libraries may be preloaded in this way, typically by using the
        syntax <literal>'$libdir/plXXX:plXXX_init'</literal> where
        <literal>XXX</literal> is <literal>pgsql</>, <literal>perl</>,
        <literal>tcl</>, or <literal>python</>.
       </para>

       <para>
        By preloading a shared library (and initializing it if
        applicable), the library startup time is avoided when the
        library is first used.  However, the time to start each new
        server process may increase slightly, even if that process never
        uses the library.  So this option is recommended only for
        libraries that will be used in most sessions.
       </para>
      </listitem>
     </varlistentry>

     </variablelist>
    </sect2>

    <sect2 id="runtime-config-resource-vacuum-cost">
     <title id="runtime-config-resource-vacuum-cost-title">
       Cost-Based Vacuum Delay
     </title>

     <para>
      During the execution of <xref linkend="sql-vacuum"
      endterm="sql-vacuum-title"> and <xref linkend="sql-analyze"
      endterm="sql-analyze-title"> commands, the system maintains an
      internal counter that keeps track of the estimated cost of the
      various I/O operations that are performed.  When the accumulated
      cost reaches a limit (specified by
      <varname>vacuum_cost_limit</varname>), the process performing
      the operation will sleep for a while (specified by
      <varname>vacuum_cost_delay</varname>). Then it will reset the
      counter and continue execution.
     </para>

     <para>
      The intent of this feature is to allow administrators to reduce
      the I/O impact of these commands on concurrent database
      activity. There are many situations in which it is not very
      important that maintenance commands like
      <command>VACUUM</command> and <command>ANALYZE</command> finish
      quickly; however, it is usually very important that these
      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>

     <para>
      This feature is disabled by default. To enable it, set the
      <varname>vacuum_cost_delay</varname> variable to a nonzero
      value.
     </para>

     <variablelist>
      <varlistentry id="guc-vacuum-cost-delay" xreflabel="vacuum_cost_delay">
       <term><varname>vacuum_cost_delay</varname> (<type>integer</type>)</term>
       <indexterm>
        <primary><varname>vacuum_cost_delay</> configuration parameter</primary>
       </indexterm>
       <listitem>
        <para>
         The length of time, in milliseconds, that the process will sleep
         when the cost limit has been exceeded.
         The default value is 0, which disables the cost-based vacuum
         delay feature.  Positive values enable cost-based vacuuming.
         Note that on many systems, the effective resolution
         of sleep delays is 10 milliseconds; setting
         <varname>vacuum_cost_delay</varname> to a value that is
         not a multiple of 10 may have the same results as setting it
         to the next higher multiple of 10.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry id="guc-vacuum-cost-page-hit" xreflabel="vacuum_cost_page_hit">
       <term><varname>vacuum_cost_page_hit</varname> (<type>integer</type>)</term>
       <indexterm>
        <primary><varname>vacuum_cost_page_hit</> configuration parameter</primary>
       </indexterm>
       <listitem>
        <para>
         The estimated cost for vacuuming a buffer found in the shared buffer
         cache. It represents the cost to lock the buffer pool, lookup
         the shared hash table and scan the content of the page. The
         default value is 1.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry id="guc-vacuum-cost-page-miss" xreflabel="vacuum_cost_page_miss">
       <term><varname>vacuum_cost_page_miss</varname> (<type>integer</type>)</term>
       <indexterm>
        <primary><varname>vacuum_cost_page_miss</> configuration parameter</primary>
       </indexterm>
       <listitem>
        <para>
         The estimated cost for vacuuming a buffer that has to be read from
         disk.  This represents the effort to lock the buffer pool,
         lookup the shared hash table, read the desired block in from
         the disk and scan its content. The default value is 10.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry id="guc-vacuum-cost-page-dirty" xreflabel="vacuum_cost_page_dirty">
       <term><varname>vacuum_cost_page_dirty</varname> (<type>integer</type>)</term>
       <indexterm>
        <primary><varname>vacuum_cost_page_dirty</> configuration parameter</primary>
       </indexterm>
       <listitem>
        <para>
         The estimated cost charged when vacuum modifies a block that was
         previously clean. It represents the extra I/O required to
         flush the dirty block out to disk again. The default value is
         20.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry id="guc-vacuum-cost-limit" xreflabel="vacuum_cost_limit">
       <term><varname>vacuum_cost_limit</varname> (<type>integer</type>)</term>
       <indexterm>
        <primary><varname>vacuum_cost_limit</> configuration parameter</primary>
       </indexterm>
       <listitem>
        <para>
         The accumulated cost that will cause the vacuuming process to sleep.
         The default value is 200.
        </para>
       </listitem>
      </varlistentry>
     </variablelist>

     <note>
      <para>
       There are certain operations that hold critical locks and should
       therefore complete as quickly as possible.  Cost-based vacuum
       delays do not occur during such operations.  Therefore it is
       possible that the cost accumulates far higher than the specified
       limit.  To avoid uselessly long delays in such cases, the actual
       delay is calculated as <varname>vacuum_cost_delay</varname> *
       <varname>accumulated_balance</varname> /
       <varname>vacuum_cost_limit</varname> with a maximum of
       <varname>vacuum_cost_delay</varname> * 4.
      </para>
     </note>
    </sect2>

    <sect2 id="runtime-config-resource-background-writer">
     <title>Background Writer</title>

     <para>
      Beginning in <productname>PostgreSQL</> 8.0, there is a separate server
      process called the <firstterm>background writer</>, whose sole function
      is to issue writes of <quote>dirty</> shared buffers.  The intent is
      that server processes handling user queries should seldom or never have
      to wait for a write to occur, because the background writer will do it.
      This arrangement also reduces the performance penalty associated with
      checkpoints.  The background writer will continuously trickle out dirty
      pages to disk, so that only a few pages will need to be forced out when
      checkpoint time arrives, instead of the storm of dirty-buffer writes that
      formerly occurred at each checkpoint.  However there is a net overall
      increase in I/O load, because where a repeatedly-dirtied page might
      before have been written only once per checkpoint interval, the
      background writer might write it several times in the same interval.
      In most situations a continuous low load is preferable to periodic
      spikes, but the parameters discussed in this subsection can be used to tune
      the behavior for local needs.
     </para>

     <variablelist>
      <varlistentry id="guc-bgwriter-delay" xreflabel="bgwriter_delay">
       <term><varname>bgwriter_delay</varname> (<type>integer</type>)</term>
       <indexterm>
        <primary><varname>bgwriter_delay</> configuration parameter</primary>
       </indexterm>
       <listitem>
        <para>
         Specifies the delay between activity rounds for the
         background writer.  In each round the writer issues writes
         for some number of dirty buffers (controllable by the
         following parameters).  It then sleeps for <varname>bgwriter_delay</>
         milliseconds, and repeats.  The default value is 200. Note
         that on many systems, the effective resolution of sleep
         delays is 10 milliseconds; setting <varname>bgwriter_delay</>
         to a value that is not a multiple of 10 may have the same
         results as setting it to the next higher multiple of 10.
         This option can be set at server start or in the
         <filename>postgresql.conf</filename> file.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry id="guc-bgwriter-lru-percent" xreflabel="bgwriter_lru_percent">
       <term><varname>bgwriter_lru_percent</varname> (<type>floating point</type>)</term>
       <indexterm>
        <primary><varname>bgwriter_lru_percent</> configuration parameter</primary>
       </indexterm>
       <listitem>
        <para>
         To reduce the probability that server processes will need to issue
         their own writes, the background writer tries to write buffers that
         are likely to be recycled soon.  In each round, it examines up to
         <varname>bgwriter_lru_percent</> of the buffers that are nearest to
         being recycled, and writes any that are dirty.
         The default value is 1.0 (this is a percentage of the total number
         of shared buffers).
         This option can be set at server start or in the
         <filename>postgresql.conf</filename> file.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry id="guc-bgwriter-lru-maxpages" xreflabel="bgwriter_lru_maxpages">
       <term><varname>bgwriter_lru_maxpages</varname> (<type>integer</type>)</term>
       <indexterm>
        <primary><varname>bgwriter_lru_maxpages</> configuration parameter</primary>
       </indexterm>
       <listitem>
        <para>
         In each round, no more than this many buffers will be written
         as a result of scanning soon-to-be-recycled buffers.
         The default value is 5.
         This option can be set at server start or in the
         <filename>postgresql.conf</filename> file.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry id="guc-bgwriter-all-percent" xreflabel="bgwriter_all_percent">
       <term><varname>bgwriter_all_percent</varname> (<type>floating point</type>)</term>
       <indexterm>
        <primary><varname>bgwriter_all_percent</> configuration parameter</primary>
       </indexterm>
       <listitem>
        <para>
         To reduce the amount of work that will be needed at checkpoint time,
         the background writer also does a circular scan through the entire
         buffer pool, writing buffers that are found to be dirty.
         In each round, it examines up to
         <varname>bgwriter_all_percent</> of the buffers for this purpose.
         The default value is 0.333 (this is a percentage of the total number
         of shared buffers).  With the default <varname>bgwriter_delay</>
         setting, this will allow the entire shared buffer pool to be scanned
         about once per minute.
         This option can be set at server start or in the
         <filename>postgresql.conf</filename> file.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry id="guc-bgwriter-all-maxpages" xreflabel="bgwriter_all_maxpages">
       <term><varname>bgwriter_all_maxpages</varname> (<type>integer</type>)</term>
       <indexterm>
        <primary><varname>bgwriter_all_maxpages</> configuration parameter</primary>
       </indexterm>
       <listitem>
        <para>
         In each round, no more than this many buffers will be written
         as a result of the scan of the entire buffer pool.  (If this
         limit is reached, the scan stops, and resumes at the next buffer
         during the next round.)
         The default value is 5.
         This option can be set at server start or in the
         <filename>postgresql.conf</filename> file.
        </para>
       </listitem>
      </varlistentry>
     </variablelist>

     <para>
      Smaller values of <varname>bgwriter_all_percent</varname> and
      <varname>bgwriter_all_maxpages</varname> reduce the extra I/O load
      caused by the background writer, but leave more work to be done
      at checkpoint time.  To reduce load spikes at checkpoints,
      increase these two values.
      Similarly, smaller values of <varname>bgwriter_lru_percent</varname> and
      <varname>bgwriter_lru_maxpages</varname> reduce the extra I/O load
      caused by the background writer, but make it more likely that server
      processes will have to issue writes for themselves, delaying interactive
      queries.
      To disable background writing entirely,
      set both <varname>maxpages</varname> values and/or both
      <varname>percent</varname> values to zero.
     </para>
    </sect2>
   </sect1>