Sophie: postgresql8.2-docs-8.2.14-1mdv2010.0 i586

postgresql8.2-docs-8.2.14-1mdv2010.0.i586.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Resource Consumption</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REV="MADE"
HREF="mailto:pgsql-docs@postgresql.org"><LINK
REL="HOME"
TITLE="PostgreSQL 8.2.14 Documentation"
HREF="index.html"><LINK
REL="UP"
TITLE="Server Configuration"
HREF="runtime-config.html"><LINK
REL="PREVIOUS"
TITLE="Connections and Authentication"
HREF="runtime-config-connection.html"><LINK
REL="NEXT"
TITLE="Write Ahead Log"
HREF="runtime-config-wal.html"><LINK
REL="STYLESHEET"
TYPE="text/css"
HREF="stylesheet.css"><META
HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-8859-1"><META
NAME="creation"
CONTENT="2009-09-04T05:25:47"></HEAD
><BODY
CLASS="SECT1"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="5"
ALIGN="center"
VALIGN="bottom"
>PostgreSQL 8.2.14 Documentation</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="runtime-config-connection.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="runtime-config.html"
>Fast Backward</A
></TD
><TD
WIDTH="60%"
ALIGN="center"
VALIGN="bottom"
>Chapter 17. Server Configuration</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="top"
><A
HREF="runtime-config.html"
>Fast Forward</A
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="top"
><A
HREF="runtime-config-wal.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="RUNTIME-CONFIG-RESOURCE"
>17.4. Resource Consumption</A
></H1
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="RUNTIME-CONFIG-RESOURCE-MEMORY"
>17.4.1. Memory</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><A
NAME="GUC-SHARED-BUFFERS"
></A
><TT
CLASS="VARNAME"
>shared_buffers</TT
> (<TT
CLASS="TYPE"
>integer</TT
>)</DT
><DD
><P
>        Sets the amount of memory the database server uses for shared
        memory buffers.  The default is typically 32 megabytes
        (<TT
CLASS="LITERAL"
>32MB</TT
>), but may be less if your kernel settings will
        not support it (as determined during <SPAN
CLASS="APPLICATION"
>initdb</SPAN
>).
        This setting must be at least 128 kilobytes and at least 16
        kilobytes times <A
HREF="runtime-config-connection.html#GUC-MAX-CONNECTIONS"
>max_connections</A
>.  (Non-default
        values of <TT
CLASS="SYMBOL"
>BLCKSZ</TT
> change the minimum.)  However,
        settings significantly higher than the minimum are usually needed
        for good performance.  Several tens of megabytes are recommended
        for production installations.  This parameter can only be set at
        server start.
       </P
><P
>        Increasing this parameter may cause <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
>
        to request more <SPAN
CLASS="SYSTEMITEM"
>System V</SPAN
> shared
        memory than your operating system's default configuration
        allows. See <A
HREF="kernel-resources.html#SYSVIPC"
>Section 16.4.1</A
> for information on how to
        adjust those parameters, if necessary.
       </P
></DD
><DT
><A
NAME="GUC-TEMP-BUFFERS"
></A
><TT
CLASS="VARNAME"
>temp_buffers</TT
> (<TT
CLASS="TYPE"
>integer</TT
>)</DT
><DD
><P
>        Sets the maximum number of temporary buffers used by each database
        session.  These are session-local buffers used only for access to
        temporary tables.  The default is eight megabytes
        (<TT
CLASS="LITERAL"
>8MB</TT
>).  The setting can be changed within individual
        sessions, but only up until the first use of temporary tables
        within a session; subsequent attempts to change the value will
        have no effect on that session.
       </P
><P
>        A session will allocate temporary buffers as needed up to the limit
        given by <TT
CLASS="VARNAME"
>temp_buffers</TT
>.  The cost of setting a large
        value in sessions that do not actually need a lot of temporary
        buffers is only a buffer descriptor, or about 64 bytes, per
        increment in <TT
CLASS="VARNAME"
>temp_buffers</TT
>.  However if a buffer is
        actually used an additional 8192 bytes will be consumed for it
        (or in general, <TT
CLASS="SYMBOL"
>BLCKSZ</TT
> bytes).
       </P
></DD
><DT
><A
NAME="GUC-MAX-PREPARED-TRANSACTIONS"
></A
><TT
CLASS="VARNAME"
>max_prepared_transactions</TT
> (<TT
CLASS="TYPE"
>integer</TT
>)</DT
><DD
><P
>        Sets the maximum number of transactions that can be in the
        <SPAN
CLASS="QUOTE"
>"prepared"</SPAN
> state simultaneously (see <A
HREF="sql-prepare-transaction.html"
><I
>PREPARE TRANSACTION</I
></A
>).
        Setting this parameter to zero disables the prepared-transaction
        feature.
        The default is five transactions.
        This parameter can only be set at server start.
       </P
><P
>        If you are not using prepared transactions, this parameter may as
        well be set to zero.  If you are using them, you will probably
        want <TT
CLASS="VARNAME"
>max_prepared_transactions</TT
> to be at least
        as large as <A
HREF="runtime-config-connection.html#GUC-MAX-CONNECTIONS"
>max_connections</A
>, to avoid unwanted
        failures at the prepare step.
       </P
><P
>        Increasing this parameter may cause <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
>
        to request more <SPAN
CLASS="SYSTEMITEM"
>System V</SPAN
> shared
        memory than your operating system's default configuration
        allows. See <A
HREF="kernel-resources.html#SYSVIPC"
>Section 16.4.1</A
> for information on how to
        adjust those parameters, if necessary.
       </P
></DD
><DT
><A
NAME="GUC-WORK-MEM"
></A
><TT
CLASS="VARNAME"
>work_mem</TT
> (<TT
CLASS="TYPE"
>integer</TT
>)</DT
><DD
><P
>        Specifies the amount of memory to be used by internal sort operations
        and hash tables before switching to temporary disk files. The value is
        defaults to one megabyte (<TT
CLASS="LITERAL"
>1MB</TT
>).
        Note that for a complex query, several sort or hash operations might be
        running in parallel; each one will be allowed to use as much memory
        as this value specifies before it starts to put data into temporary
        files. Also, several running sessions could be doing such operations
        concurrently.  So the total memory used could be many
        times the value of <TT
CLASS="VARNAME"
>work_mem</TT
>; it is necessary to
        keep this fact in mind when choosing the value. Sort operations are
        used for <TT
CLASS="LITERAL"
>ORDER BY</TT
>, <TT
CLASS="LITERAL"
>DISTINCT</TT
>, and
        merge joins.
        Hash tables are used in hash joins, hash-based aggregation, and
        hash-based processing of <TT
CLASS="LITERAL"
>IN</TT
> subqueries.
       </P
></DD
><DT
><A
NAME="GUC-MAINTENANCE-WORK-MEM"
></A
><TT
CLASS="VARNAME"
>maintenance_work_mem</TT
> (<TT
CLASS="TYPE"
>integer</TT
>)</DT
><DD
><P
>        Specifies the maximum amount of memory to be used in maintenance
        operations, such as <TT
CLASS="COMMAND"
>VACUUM</TT
>, <TT
CLASS="COMMAND"
>CREATE
        INDEX</TT
>, and <TT
CLASS="COMMAND"
>ALTER TABLE ADD FOREIGN KEY</TT
>.  It defaults
        to 16 megabytes (<TT
CLASS="LITERAL"
>16MB</TT
>).  Since only one of these
        operations can be executed at a time by a database session, and
        an installation normally doesn't have many of them running
        concurrently, it's safe to set this value significantly larger
        than <TT
CLASS="VARNAME"
>work_mem</TT
>.  Larger settings may improve
        performance for vacuuming and for restoring database dumps.
       </P
></DD
><DT
><A
NAME="GUC-MAX-STACK-DEPTH"
></A
><TT
CLASS="VARNAME"
>max_stack_depth</TT
> (<TT
CLASS="TYPE"
>integer</TT
>)</DT
><DD
><P
>        Specifies the maximum safe depth of the server's execution stack.
        The ideal setting for this parameter is the actual stack size limit
        enforced by the kernel (as set by <TT
CLASS="LITERAL"
>ulimit -s</TT
> or local
        equivalent), less a safety margin of a megabyte or so.  The safety
        margin is needed because the stack depth is not checked in every
        routine in the server, but only in key potentially-recursive routines
        such as expression evaluation.  The default setting is two
        megabytes (<TT
CLASS="LITERAL"
>2MB</TT
>), which is conservatively small and
        unlikely to risk crashes.  However, it may be too small to allow
        execution of complex functions.  Only superusers can change this
        setting.
       </P
><P
>        Setting <TT
CLASS="VARNAME"
>max_stack_depth</TT
> higher than
        the actual kernel limit will mean that a runaway recursive function
        can crash an individual backend process.  On platforms where
        <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
> can determine the kernel limit,
        it will not let you set this variable to an unsafe value.  However,
        not all platforms provide the information, so caution is recommended
        in selecting a value.
       </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="RUNTIME-CONFIG-RESOURCE-FSM"
>17.4.2. Free Space Map</A
></H2
><A
NAME="AEN20075"
></A
><P
>      These parameters control the size of the shared <I
CLASS="FIRSTTERM"
>free space
      map</I
>, which tracks the locations of unused space in the database.
      An undersized free space map may cause the database to consume
      increasing amounts of disk space over time, because free space that
      is not in the map cannot be re-used; instead <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
>
      will request more disk space from the operating system when it needs
      to store new data.
      The last few lines displayed by a database-wide <TT
CLASS="COMMAND"
>VACUUM VERBOSE</TT
> 
      command can help in determining if the current settings are adequate.
      A <TT
CLASS="LITERAL"
>NOTICE</TT
> message is also printed during such an operation
      if the current settings are too low.
     </P
><P
>      Increasing these parameters may cause <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
>
      to request more <SPAN
CLASS="SYSTEMITEM"
>System V</SPAN
> shared
      memory than your operating system's default configuration
      allows. See <A
HREF="kernel-resources.html#SYSVIPC"
>Section 16.4.1</A
> for information on how to
      adjust those parameters, if necessary.
     </P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><A
NAME="GUC-MAX-FSM-PAGES"
></A
><TT
CLASS="VARNAME"
>max_fsm_pages</TT
> (<TT
CLASS="TYPE"
>integer</TT
>)</DT
><DD
><P
>        Sets the maximum number of disk pages for which free space will
        be tracked in the shared free-space map.  Six bytes of shared memory
        are consumed for each page slot.  This setting must be at least
        16 * <TT
CLASS="VARNAME"
>max_fsm_relations</TT
>.  The default is chosen
        by <SPAN
CLASS="APPLICATION"
>initdb</SPAN
> depending on the amount of available memory,
        and can range from 20k to 200k pages.
        This parameter can only be set at server start.
       </P
></DD
><DT
><A
NAME="GUC-MAX-FSM-RELATIONS"
></A
><TT
CLASS="VARNAME"
>max_fsm_relations</TT
> (<TT
CLASS="TYPE"
>integer</TT
>)</DT
><DD
><P
>        Sets the maximum number of relations (tables and indexes) for which
        free space will be tracked in the shared free-space map.  Roughly
        seventy bytes of shared memory are consumed for each slot.
        The default is one thousand relations.
        This parameter can only be set at server start.
       </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="RUNTIME-CONFIG-RESOURCE-KERNEL"
>17.4.3. Kernel Resource Usage</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><A
NAME="GUC-MAX-FILES-PER-PROCESS"
></A
><TT
CLASS="VARNAME"
>max_files_per_process</TT
> (<TT
CLASS="TYPE"
>integer</TT
>)</DT
><DD
><P
>        Sets the maximum number of simultaneously open files allowed to each
        server subprocess. The default is one thousand files. If the kernel is enforcing
        a safe per-process limit, you don't need to worry about this setting.
        But on some platforms (notably, most BSD systems), the kernel will
        allow individual processes to open many more files than the system
        can really support when a large number of processes all try to open
        that many files. If you find yourself seeing <SPAN
CLASS="QUOTE"
>"Too many open
        files"</SPAN
> failures, try reducing this setting.
        This parameter can only be set at server start.
       </P
></DD
><DT
><A
NAME="GUC-SHARED-PRELOAD-LIBRARIES"
></A
><TT
CLASS="VARNAME"
>shared_preload_libraries</TT
> (<TT
CLASS="TYPE"
>string</TT
>)</DT
><DD
><P
>        This variable specifies one or more shared libraries that are
        to be preloaded at server start. If more than one library is to be
        loaded, separate their names with commas. For example,
        <TT
CLASS="LITERAL"
>'$libdir/mylib'</TT
> would cause
        <TT
CLASS="LITERAL"
>mylib.so</TT
> (or on some platforms,
        <TT
CLASS="LITERAL"
>mylib.sl</TT
>) to be preloaded from the installation's
        standard library directory.
        This parameter can only be set at server start.
       </P
><P
>        <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
> procedural language
        libraries can be preloaded in this way, typically by using the
        syntax <TT
CLASS="LITERAL"
>'$libdir/plXXX'</TT
> where
        <TT
CLASS="LITERAL"
>XXX</TT
> is <TT
CLASS="LITERAL"
>pgsql</TT
>, <TT
CLASS="LITERAL"
>perl</TT
>,
        <TT
CLASS="LITERAL"
>tcl</TT
>, or <TT
CLASS="LITERAL"
>python</TT
>.
       </P
><P
>        By preloading a shared library, 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 parameter is recommended only for
        libraries that will be used in most sessions. 
       </P
><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Note: </B
>        On Windows hosts, preloading a library at server start will not reduce
        the time required to start each new server process; each server process
        will re-load all preload libraries.  However, <TT
CLASS="VARNAME"
>shared_preload_libraries
        </TT
> is still useful on Windows hosts because some shared libraries may 
        need to perform certain operations that only take place at postmaster start
        (for example, a shared library may need to reserve lightweight locks
        or shared memory and you can't do that after the postmaster has started).
       </P
></BLOCKQUOTE
></DIV
><P
>        If a specified library is not found,
        the server will fail to start.
       </P
><P
>        Every  PostgreSQL-supported library has a <SPAN
CLASS="QUOTE"
>"magic
        block"</SPAN
> that is checked to guarantee compatibility.  
        For this reason, non-PostgreSQL libraries cannot be 
        loaded in this way.
       </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="RUNTIME-CONFIG-RESOURCE-VACUUM-COST"
>17.4.4. Cost-Based Vacuum Delay</A
></H2
><P
>      During the execution of <A
HREF="sql-vacuum.html"
><I
>VACUUM</I
></A
> and <A
HREF="sql-analyze.html"
><I
>ANALYZE</I
></A
> 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
      <TT
CLASS="VARNAME"
>vacuum_cost_limit</TT
>), the process performing
      the operation will sleep for a while (specified by
      <TT
CLASS="VARNAME"
>vacuum_cost_delay</TT
>). Then it will reset the
      counter and continue execution.
     </P
><P
>      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
      <TT
CLASS="COMMAND"
>VACUUM</TT
> and <TT
CLASS="COMMAND"
>ANALYZE</TT
> 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.
     </P
><P
>      This feature is disabled by default. To enable it, set the
      <TT
CLASS="VARNAME"
>vacuum_cost_delay</TT
> variable to a nonzero
      value.
     </P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><A
NAME="GUC-VACUUM-COST-DELAY"
></A
><TT
CLASS="VARNAME"
>vacuum_cost_delay</TT
> (<TT
CLASS="TYPE"
>integer</TT
>)</DT
><DD
><P
>         The length of time, in milliseconds, that the process will sleep
         when the cost limit has been exceeded.
         The default value is zero, 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
         <TT
CLASS="VARNAME"
>vacuum_cost_delay</TT
> 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.
        </P
></DD
><DT
><A
NAME="GUC-VACUUM-COST-PAGE-HIT"
></A
><TT
CLASS="VARNAME"
>vacuum_cost_page_hit</TT
> (<TT
CLASS="TYPE"
>integer</TT
>)</DT
><DD
><P
>         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 one.
        </P
></DD
><DT
><A
NAME="GUC-VACUUM-COST-PAGE-MISS"
></A
><TT
CLASS="VARNAME"
>vacuum_cost_page_miss</TT
> (<TT
CLASS="TYPE"
>integer</TT
>)</DT
><DD
><P
>         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.
        </P
></DD
><DT
><A
NAME="GUC-VACUUM-COST-PAGE-DIRTY"
></A
><TT
CLASS="VARNAME"
>vacuum_cost_page_dirty</TT
> (<TT
CLASS="TYPE"
>integer</TT
>)</DT
><DD
><P
>         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.
        </P
></DD
><DT
><A
NAME="GUC-VACUUM-COST-LIMIT"
></A
><TT
CLASS="VARNAME"
>vacuum_cost_limit</TT
> (<TT
CLASS="TYPE"
>integer</TT
>)</DT
><DD
><P
>         The accumulated cost that will cause the vacuuming process to sleep.
         The default value is 200.
        </P
></DD
></DL
></DIV
><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Note: </B
>       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 <TT
CLASS="VARNAME"
>vacuum_cost_delay</TT
> *
       <TT
CLASS="VARNAME"
>accumulated_balance</TT
> /
       <TT
CLASS="VARNAME"
>vacuum_cost_limit</TT
> with a maximum of
       <TT
CLASS="VARNAME"
>vacuum_cost_delay</TT
> * 4.
      </P
></BLOCKQUOTE
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="RUNTIME-CONFIG-RESOURCE-BACKGROUND-WRITER"
>17.4.5. Background Writer</A
></H2
><P
>      Beginning in <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
> 8.0, there is a separate server
      process called the <I
CLASS="FIRSTTERM"
>background writer</I
>, whose sole function
      is to issue writes of <SPAN
CLASS="QUOTE"
>"dirty"</SPAN
> 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.
     </P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><A
NAME="GUC-BGWRITER-DELAY"
></A
><TT
CLASS="VARNAME"
>bgwriter_delay</TT
> (<TT
CLASS="TYPE"
>integer</TT
>)</DT
><DD
><P
>         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 <TT
CLASS="VARNAME"
>bgwriter_delay</TT
>
         milliseconds, and repeats.  The default value is 200 milliseconds
         (<TT
CLASS="LITERAL"
>200ms</TT
>). Note that on many systems, the effective
         resolution of sleep delays is 10 milliseconds; setting
         <TT
CLASS="VARNAME"
>bgwriter_delay</TT
> 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 parameter can only be set in the
         <TT
CLASS="FILENAME"
>postgresql.conf</TT
> file or on the server command line.
        </P
></DD
><DT
><A
NAME="GUC-BGWRITER-LRU-PERCENT"
></A
><TT
CLASS="VARNAME"
>bgwriter_lru_percent</TT
> (<TT
CLASS="TYPE"
>floating point</TT
>)</DT
><DD
><P
>         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
         <TT
CLASS="VARNAME"
>bgwriter_lru_percent</TT
> of the buffers that are nearest to
         being recycled, and writes any that are dirty.
         The default value is 1.0 (1% of the total number of shared buffers).
         This parameter can only be set in the <TT
CLASS="FILENAME"
>postgresql.conf</TT
>
         file or on the server command line.
        </P
></DD
><DT
><A
NAME="GUC-BGWRITER-LRU-MAXPAGES"
></A
><TT
CLASS="VARNAME"
>bgwriter_lru_maxpages</TT
> (<TT
CLASS="TYPE"
>integer</TT
>)</DT
><DD
><P
>         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 five buffers.
         This parameter can only be set in the <TT
CLASS="FILENAME"
>postgresql.conf</TT
>
         file or on the server command line.
        </P
></DD
><DT
><A
NAME="GUC-BGWRITER-ALL-PERCENT"
></A
><TT
CLASS="VARNAME"
>bgwriter_all_percent</TT
> (<TT
CLASS="TYPE"
>floating point</TT
>)</DT
><DD
><P
>         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
         <TT
CLASS="VARNAME"
>bgwriter_all_percent</TT
> of the buffers for this purpose.
         The default value is 0.333 (0.333% of the total number
         of shared buffers).  With the default <TT
CLASS="VARNAME"
>bgwriter_delay</TT
>
         setting, this will allow the entire shared buffer pool to be scanned
         about once per minute.
         This parameter can only be set in the <TT
CLASS="FILENAME"
>postgresql.conf</TT
>
         file or on the server command line.
        </P
></DD
><DT
><A
NAME="GUC-BGWRITER-ALL-MAXPAGES"
></A
><TT
CLASS="VARNAME"
>bgwriter_all_maxpages</TT
> (<TT
CLASS="TYPE"
>integer</TT
>)</DT
><DD
><P
>         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 five buffers.
         This parameter can only be set in the <TT
CLASS="FILENAME"
>postgresql.conf</TT
>
         file or on the server command line.
        </P
></DD
></DL
></DIV
><P
>      Smaller values of <TT
CLASS="VARNAME"
>bgwriter_all_percent</TT
> and
      <TT
CLASS="VARNAME"
>bgwriter_all_maxpages</TT
> 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 <TT
CLASS="VARNAME"
>bgwriter_lru_percent</TT
> and
      <TT
CLASS="VARNAME"
>bgwriter_lru_maxpages</TT
> 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 <TT
CLASS="VARNAME"
>maxpages</TT
> values and/or both
      <TT
CLASS="VARNAME"
>percent</TT
> values to zero.
     </P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="runtime-config-connection.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="runtime-config-wal.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Connections and Authentication</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="runtime-config.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Write Ahead Log</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>