Make the documentation of GUC variables a separate chapter, rather than

a section of the "Server Run-time Environment" chapter. Also, move the
SGML for the new chapter to a separate file and fix the resulting
fallout.

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
new file mode 100644 (file)
index 0000000..de5e71e
--- /dev/null
+++ b/doc/src/sgml/config.sgml
@@ -0,0 +1,4238 @@
+
+
+  Run-time Configuration
+
+  
+   configuration
+   of the server
+  
+
+  
+   There are many configuration parameters that affect the behavior of
+   the database system. In the first section of this chapter, we
+   describe how to set configuration chapters. The subsequent sections
+   discuss each parameter in detail.
+  
+
+  
+   Setting Parameters
+
+   
+    All parameter names are case-insensitive. Every parameter takes a
+    value of one of four types: boolean, integer, floating point,
+    or string. Boolean values may be written as ON,
+    OFF, TRUE,
+    FALSE, YES,
+    NO, 1, 0
+    (all case-insensitive) or any unambiguous prefix of these.
+   
+
+   
+    One way to set these parameters is to edit the file
+    postgresql.confpostgresql.conf,
+    which is normally kept in the data directory. (initdb
+    installs a default copy there.) An example of what this file might look
+    like is:
+
+# This is a comment
+log_connections = yes
+log_destination = 'syslog'
+search_path = '$user, public'
+
+    One parameter is specified per line. The equal sign between name and
+    value is optional. Whitespace is insignificant and blank lines are
+    ignored. Hash marks (#) introduce comments
+    anywhere.  Parameter values that are not simple identifiers or
+    numbers must be single-quoted.
+  
+
+   
+    
+     SIGHUP
+    
+    The configuration file is reread whenever the
+    postmaster process receives a
+    SIGHUP signal (which is most easily sent by means
+    of pg_ctl reload). The postmaster
+    also propagates this signal to all currently running server
+    processes so that existing sessions also get the new
+    value. Alternatively, you can send the signal to a single server
+    process directly.  Some parameters can only be set at server start;
+    any changes to their entries in the configuration file will be ignored
+    until the server is restarted.
+   
+
+   
+    A second way to set these configuration parameters is to give them
+    as a command line option to the postmaster, such as:
+
+postmaster -c log_connections=yes -c log_destination='syslog'
+
+    Command-line options override any conflicting settings in
+    postgresql.conf.  Note that this means you won't
+    be able to change the value on-the-fly by editing
+    postgresql.conf, so while the command-line
+    method may be convenient, it can cost you flexibility later.
+   
+
+   
+    Occasionally it is useful to give a command line option to
+    one particular session only. The environment variable
+    PGOPTIONS can be used for this purpose on the
+    client side:
+
+env PGOPTIONS='-c geqo=off' psql
+
+    (This works for any libpq-based client application, not
+    just psql.) Note that this won't work for
+    parameters that are fixed when the server is started or that must be
+    specified in postgresql.conf.
+   
+
+   
+    Furthermore, it is possible to assign a set of option settings to
+    a user or a database.  Whenever a session is started, the default
+    settings for the user and database involved are loaded.  The
+    commands 
+    and ,
+    respectively, are used to configure these settings.  Per-database
+    settings override anything received from the
+    postmaster command-line or the configuration
+    file, and in turn are overridden by per-user settings; both are
+    overridden by per-session options.
+   
+
+   
+    Some parameters can be changed in individual SQL
+    sessions with the 
+    command, for example:
+
+SET ENABLE_SEQSCAN TO OFF;
+
+    If SET is allowed, it overrides all other sources of
+    values for the parameter. Some parameters cannot be changed via
+    SET: for example, if they control behavior that
+    cannot reasonably be changed without restarting
+    PostgreSQL.  Also, some parameters can
+    be modified via SET or ALTER by superusers,
+    but not by ordinary users.
+   
+
+   
+    The 
+    command allows inspection of the current values of all parameters.
+   
+
+   
+    The virtual table pg_settings
+    (described in ) also allows
+    displaying and updating session run-time parameters.  It is equivalent
+    to SHOW and SET, but can be more convenient
+    to use because it can be joined with other tables, or selected from using
+    any desired selection condition.
+   
+  
+
+   
+    File Locations
+
+     
+      In addition to the postgresql.conf file
+      already mentioned, PostgreSQL uses
+      two other manually-edited configuration files, which control
+      client authentication (their use is discussed in 
+      linkend="client-authentication">).  By default, all three
+      configuration files are stored in the database cluster's data
+      directory.  The options described in this section allow the
+      configuration files to be placed elsewhere.  (Doing so can ease
+      administration.  In particular it is often easier to ensure that
+      the configuration files are properly backed-up when they are
+      kept separate.)
+     
+
+     
+     
+      data_directory (string)
+      
+       data_directory configuration parameter
+      
+      
+       
+         Specifies the directory to use for data storage.
+         This option can only be set at server start.
+       
+      
+     
+
+     
+      config_file (string)
+      
+       config_file configuration parameter
+      
+      
+       
+         Specifies the main server configuration file
+         (customarily called postgresql.conf).
+         This option can only be set on the postmaster command line.
+       
+      
+     
+
+     
+      hba_file (string)
+      
+       hba_file configuration parameter
+      
+      
+       
+         Specifies the configuration file for host-based authentication
+         (customarily called pg_hba.conf).
+         This option can only be set at server start.
+       
+      
+     
+
+     
+      ident_file (string)
+      
+       ident_file configuration parameter
+      
+      
+       
+         Specifies the configuration file for
+         ident authentication
+         (customarily called pg_ident.conf).
+         This option can only be set at server start.
+       
+      
+     
+
+     
+      external_pid_file (string)
+      
+       external_pid_file configuration parameter
+      
+      
+       
+        Specifies the name of an additional process-id (PID) file that the
+        postmaster should create for use by server
+        administration programs.
+        This option can only be set at server start.
+       
+      
+     
+     
+
+     
+      In a default installation, none of the above options are set explicitly.
+      Instead, the
+      data directory is specified by the -D command-line
+      option or the PGDATA environment variable, and the
+      configuration files are all found within the data directory.
+     
+
+     
+      If you wish to keep the configuration files elsewhere than the
+      data directory, the postmaster's -D
+      command-line option or PGDATA environment variable
+      must point to the directory containing the configuration files,
+      and the data_directory option must be set in
+      postgresql.conf (or on the command line) to show
+      where the data directory is actually located.  Notice that
+      data_directory overrides -D and
+      PGDATA for the location
+      of the data directory, but not for the location of the configuration
+      files.
+     
+
+     
+      If you wish, you can specify the configuration file names and locations
+      individually using the options config_file,
+      hba_file and/or ident_file.
+      config_file can only be specified on the 
+      postmaster command line, but the others can be
+      set within the main configuration file.  If all three options plus
+      data_directory are explicitly set, then it is not necessary
+      to specify -D or PGDATA.
+     
+
+     
+      When setting any of these options, a relative path will be interpreted
+      with respect to the directory in which the postmaster
+      is started.
+     
+   
+
+   
+    Connections and Authentication
+
+    
+     Connection Settings
+
+     
+
+     
+      listen_addresses (string)
+      
+       listen_addresses configuration parameter
+      
+      
+       
+         Specifies the TCP/IP address(es) on which the server is
+         to listen for connections from client applications.  
+         The value takes the form of a comma-separated list of host names
+         and/or numeric IP addresses.  The special entry *
+         corresponds to all available IP interfaces.
+         If the list is empty, the server does not listen on any IP interface
+         at all, in which case only Unix-domain sockets can be used to connect
+         to it.
+         The default value is localhost,
+         which allows only local loopback connections to be made.
+         This parameter can only be set at server start.
+       
+      
+     
+
+     
+      port (integer)
+      
+       port configuration parameter
+      
+      
+       
+        The TCP port the server listens on; 5432 by default.  Note that the
+        same port number is used for all IP addresses the server listens on.
+        This parameter can only be set at server start.
+       
+      
+     
+
+     
+      max_connections (integer)
+      
+       max_connections configuration parameter
+      
+      
+       
+        Determines the maximum number of concurrent connections to the
+        database server. The default is typically 100, but may be less
+        if your kernel settings will not support it (as determined
+        during initdb).  This parameter can only be
+        set at server start.
+       
+
+       
+        Increasing this parameter may cause PostgreSQL
+        to request more System V shared
+        memory or semaphores than your operating system's default configuration
+        allows. See  for information on how to
+        adjust those parameters, if necessary.
+       
+      
+     
+     
+     
+     xreflabel="superuser_reserved_connections">
+      superuser_reserved_connections
+      (integer)
+      
+       superuser_reserved_connections configuration parameter
+      
+      
+       
+        Determines the number of connection slots that
+        are reserved for connections by PostgreSQL
+        superusers.  At most 
+        connections can ever be active simultaneously.  Whenever the
+        number of active concurrent connections is at least
+        max_connections minus
+        superuser_reserved_connections, new
+        connections will be accepted only for superusers.
+       
+
+       
+        The default value is 2. The value must be less than the value of
+        max_connections. This parameter can only be
+        set at server start.
+       
+      
+     
+
+     
+      unix_socket_directory (string)
+      
+       unix_socket_directory configuration parameter
+      
+      
+       
+        Specifies the directory of the Unix-domain socket on which the
+        server is to listen for
+        connections from client applications.  The default is normally
+        /tmp, but can be changed at build time.
+        This parameter can only be set at server start.
+       
+      
+     
+
+     
+      unix_socket_group (string)
+      
+       unix_socket_group configuration parameter
+      
+      
+       
+        Sets the owning group of the Unix-domain socket.  (The owning
+        user of the socket is always the user that starts the
+        server.)  In combination with the option
+        unix_socket_permissions this can be used as
+        an additional access control mechanism for Unix-domain connections.
+        By default this is the empty string, which uses the default
+        group for the current user.  This option can only be set at
+        server start.
+       
+      
+     
+
+     
+      unix_socket_permissions (integer)
+      
+       unix_socket_permissions configuration parameter
+      
+      
+       
+        Sets the access permissions of the Unix-domain socket.  Unix-domain
+        sockets use the usual Unix file system permission set.
+        The option value is expected to be a numeric mode
+        specification in the form accepted by the
+        chmod and umask
+        system calls.  (To use the customary octal format the number
+        must start with a 0 (zero).)
+       
+
+       
+        The default permissions are 0777, meaning
+        anyone can connect. Reasonable alternatives are
+        0770 (only user and group, see also
+        unix_socket_group) and 0700
+        (only user). (Note that for a Unix-domain socket, only write
+        permission matters and so there is no point in setting or revoking
+        read or execute permissions.)
+       
+
+       
+        This access control mechanism is independent of the one
+        described in .
+       
+
+       
+        This option can only be set at server start.
+       
+      
+     
+     
+     
+      bonjour_name (string)
+      
+       bonjour_name configuration parameter
+      
+      
+       
+        Specifies the Bonjour broadcast
+        name.  By default, the computer name is used, specified as an
+        empty string ''.  This option is ignored if the server was not
+        compiled with Bonjour support.  This
+        option can only be set at server start.
+       
+      
+     
+     
+     
+      tcp_keepalives_idle (integer)
+      
+       tcp_keepalives_idle configuration parameter
+      
+      
+       
+        On systems that support the TCP_KEEPIDLE socket option, specifies the
+        number of seconds between sending keepalives on an otherwise idle
+        connection. A value of 0 uses the system default. If TCP_KEEPIDLE is
+        not supported, this parameter must be 0. This option is ignored for
+        connections made via a Unix-domain socket.
+       
+      
+     
+     
+     
+      tcp_keepalives_interval (integer)
+      
+       tcp_keepalives_interval configuration parameter
+      
+      
+       
+        On systems that support the TCP_KEEPINTVL socket option, specifies how
+        long, in seconds, to wait for a response to a keepalive before
+        retransmitting. A value of 0 uses the system default. If TCP_KEEPINTVL
+        is not supported, this parameter must be 0. This option is ignored
+        for connections made via a Unix-domain socket.
+       
+      
+     
+     
+     
+      tcp_keepalives_count (integer)
+      
+       tcp_keepalives_count configuration parameter
+      
+      
+       
+        On systems that support the TCP_KEEPCNT socket option, specifies how
+        many keepalives may be lost before the connection is considered dead. 
+        A value of 0 uses the system default. If TCP_KEEPINTVL is not
+        supported, this parameter must be 0.
+       
+      
+     
+     
+     
+     
+     
+     Security and Authentication
+     
+     
+     
+      authentication_timeout (integer)
+      timeoutclient authentication
+      client authenticationtimeout during
+      
+       authentication_timeout configuration parameter
+      
+
+      
+       
+        Maximum time to complete client authentication, in seconds. If a
+        would-be client has not completed the authentication protocol in
+        this much time, the server breaks the connection. This prevents
+        hung clients from occupying a connection indefinitely. This
+        option can only be set at server start or in the
+        postgresql.conf file. The default is 60.
+       
+      
+     
+     
+     
+      ssl (boolean)
+      
+       ssl configuration parameter
+      
+      
+       
+        Enables SSL connections. Please read
+         before using this. The default
+        is off. This parameter can only be set at server
+        start.
+       
+      
+     
+
+     
+      password_encryption (boolean)
+      
+       password_encryption configuration parameter
+      
+      
+       
+        When a password is specified in 
+        linkend="sql-createuser" endterm="sql-createuser-title"> or
+        
+        without writing either ENCRYPTED or
+        UNENCRYPTED, this option determines whether the
+        password is to be encrypted. The default is on
+        (encrypt the password).
+       
+      
+     
+
+     
+      krb_server_keyfile (string)
+      
+       krb_server_keyfile configuration parameter
+      
+      
+       
+        Sets the location of the Kerberos server key file. See
+         for details. This parameter
+        can only be set at server start.
+       
+      
+     
+
+     
+      krb_srvname (string)
+      
+       krb_srvname configuration parameter
+      
+      
+       
+        Sets the Kerberos service name. See 
+        for details.  This parameter can only be set at server start.
+       
+      
+     
+
+     
+      krb_server_hostname (string)
+      
+       krb_server_hostname configuration parameter
+      
+      
+       
+        Sets the hostname part of the service principal.
+        This, combined with krb_srvname, is used to generate
+        the complete service principal, i.e.
+        krb_server_hostname/krb_server_hostname@REALM.
+       
+       
+        If not set, the default is to allow any service principal matching an entry
+        in the keytab.  See  for details.
+        This parameter can only be set at server start.
+       
+      
+     
+
+     
+      krb_caseins_users (boolean)
+      
+       krb_caseins_users configuration parameter
+      
+      
+       
+        Sets if Kerberos usernames should be treated case-insensitively.
+        The default is off (case sensitive). This parameter
+        can only be set at server start.
+       
+      
+     
+
+     
+      db_user_namespace (boolean)
+      
+       db_user_namespace configuration parameter
+      
+      
+       
+        This enables per-database user names.  It is off by default.
+       
+
+       
+        If this is on, you should create users as username@dbname.
+        When username is passed by a connecting client,
+        @ and the database name are appended to the user
+        name and that database-specific user name is looked up by the
+        server. Note that when you create users with names containing
+        @ within the SQL environment, you will need to
+        quote the user name.
+       
+
+       
+        With this option enabled, you can still create ordinary global
+        users.  Simply append @ when specifying the user
+        name in the client.  The @ will be stripped off
+        before the user name is looked up by the server.
+       
+
+       
+        
+         This feature is intended as a temporary measure until a
+         complete solution is found.  At that time, this option will
+         be removed.
+        
+       
+      
+     
+
+    
+    
+   
+
+   
+    Resource Consumption
+
+    
+     Memory
+
+     
+     
+      shared_buffers (integer)
+      
+       shared_buffers configuration parameter
+      
+      
+       
+        Sets the number of shared memory buffers used by the database
+        server. The default is typically 1000, but may be less if your
+        kernel settings will not support it (as determined during
+        initdb).  Each buffer is 8192 bytes, unless a
+        different value of BLCKSZ was chosen when building
+        the server.  This setting must be at least 16, as well as at
+        least twice the value of ;
+        however, settings significantly higher than the minimum are
+        usually needed for good performance.  Values of a few thousand
+        are recommended for production installations.  This option can
+        only be set at server start.
+       
+
+       
+        Increasing this parameter may cause PostgreSQL
+        to request more System V shared
+        memory than your operating system's default configuration
+        allows. See  for information on how to
+        adjust those parameters, if necessary.
+       
+      
+     
+
+     
+      temp_buffers (integer)
+      
+       temp_buffers configuration parameter
+      
+      
+       
+        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 1000.  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.
+       
+
+       
+        A session will allocate temporary buffers as needed up to the limit
+        given by temp_buffers.  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 temp_buffers.  However if a buffer is
+        actually used an additional 8192 bytes will be consumed for it
+        (or in general, BLCKSZ bytes).
+       
+      
+     
+
+     
+      max_prepared_transactions (integer)
+      
+       max_prepared_transactions configuration parameter
+      
+      
+       
+        Sets the maximum number of transactions that can be in the
+        prepared state simultaneously (see 
+        linkend="sql-prepare-transaction"
+        endterm="sql-prepare-transaction-title">).
+        Setting this parameter to zero disables the prepared-transaction
+        feature.
+        The default is 5.
+        This option can only be set at server start.
+       
+
+       
+        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 max_prepared_transactions to be at least
+        as large as , to avoid unwanted
+        failures at the prepare step.
+       
+
+       
+        Increasing this parameter may cause PostgreSQL
+        to request more System V shared
+        memory than your operating system's default configuration
+        allows. See  for information on how to
+        adjust those parameters, if necessary.
+       
+      
+     
+
+     
+      work_mem (integer)
+      
+       work_mem configuration parameter
+      
+      
+       
+        Specifies the amount of memory to be used by internal sort operations
+        and hash tables before switching to temporary disk files. The value is
+        specified in kilobytes, and defaults to 1024 kilobytes (1 MB).
+        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 work_mem; it is necessary to
+        keep this fact in mind when choosing the value. Sort operations are
+        used for ORDER BY, DISTINCT, and
+        merge joins.
+        Hash tables are used in hash joins, hash-based aggregation, and
+        hash-based processing of IN subqueries.
+       
+      
+     
+     
+     
+      maintenance_work_mem (integer)
+      
+       maintenance_work_mem configuration parameter
+      
+      
+       
+        Specifies the maximum amount of memory to be used in maintenance
+        operations, such as VACUUM, CREATE
+        INDEX, and ALTER TABLE ADD FOREIGN KEY.
+        The value is specified in kilobytes, and defaults to 16384 kilobytes
+        (16 MB).  Since only one of these operations can be executed at 
+        a time by a database session, and an installation normally doesn't
+        have very many of them happening concurrently, it's safe to set this
+        value significantly larger than work_mem.  Larger
+        settings may improve performance for vacuuming and for restoring
+        database dumps.
+       
+      
+     
+
+     
+      max_stack_depth (integer)
+      
+       max_stack_depth configuration parameter
+      
+      
+       
+        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 ulimit -s 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.  Setting the parameter higher than
+        the actual kernel limit will mean that a runaway recursive function
+        can crash an individual backend process.  The default setting is
+        2048 KB (two megabytes), which is conservatively small and unlikely
+        to risk crashes.  However, it may be too small to allow execution
+        of complex functions.
+       
+      
+     
+
+     
+     
+     
+     Free Space Map
+
+     
+      free space map
+     
+
+     
+      These parameters control the size of the shared free space
+      map, 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 PostgreSQL
+      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 VACUUM VERBOSE 
+      command can help in determining if the current settings are adequate.
+      A NOTICE message is also printed during such an operation
+      if the current settings are too low.
+     
+
+     
+      Increasing these parameters may cause PostgreSQL
+      to request more System V shared
+      memory than your operating system's default configuration
+      allows. See  for information on how to
+      adjust those parameters, if necessary.
+     
+
+     
+     
+      max_fsm_pages (integer)
+      
+       max_fsm_pages configuration parameter
+      
+      
+       
+        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 more than
+        16 * max_fsm_relations.  The default is 20000.
+        This option can only be set at server start.
+       
+      
+     
+
+     
+      max_fsm_relations (integer)
+      
+       max_fsm_relations configuration parameter
+      
+      
+       
+        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 1000.
+        This option can only be set at server start.
+       
+      
+     
+     
+     
+     
+     
+     Kernel Resource Usage
+     
+
+     
+      max_files_per_process (integer)
+      
+       max_files_per_process configuration parameter
+      
+      
+       
+        Sets the maximum number of simultaneously open files allowed to each
+        server subprocess. The default is 1000. 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 Too many open
+        files failures, try reducing this setting.
+        This option can only be set at server start.
+       
+      
+     
+     
+     
+      preload_libraries (string)
+      
+       preload_libraries configuration parameter
+      
+      
+       
+        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
+        '$libdir/mylib:mylib_init' would cause
+        mylib to be preloaded and mylib_init
+        to be executed. If more than one library is to be loaded,
+        separate their names with commas.
+       
+
+       
+        If a specified library or initialization function is not found,
+        the server will fail to start.
+       
+
+       
+        PostgreSQL procedural language
+        libraries may be preloaded in this way, typically by using the
+        syntax '$libdir/plXXX:plXXX_init' where
+        XXX is pgsql, perl,
+        tcl, or python.
+       
+
+       
+        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.
+       
+      
+     
+
+     
+    
+
+    
+     
+       Cost-Based Vacuum Delay
+     
+
+     
+      During the execution of 
+      endterm="sql-vacuum-title"> and 
+      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
+      vacuum_cost_limit), the process performing
+      the operation will sleep for a while (specified by
+      vacuum_cost_delay). Then it will reset the
+      counter and continue execution.
+     
+
+     
+      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
+      VACUUM and ANALYZE 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.
+     
+
+     
+      This feature is disabled by default. To enable it, set the
+      vacuum_cost_delay variable to a nonzero
+      value.
+     
+
+     
+      
+       vacuum_cost_delay (integer)
+       
+        vacuum_cost_delay configuration parameter
+       
+       
+        
+         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
+         vacuum_cost_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.
+        
+       
+      
+
+      
+       vacuum_cost_page_hit (integer)
+       
+        vacuum_cost_page_hit configuration parameter
+       
+       
+        
+         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.
+        
+       
+      
+
+      
+       vacuum_cost_page_miss (integer)
+       
+        vacuum_cost_page_miss configuration parameter
+       
+       
+        
+         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.
+        
+       
+      
+
+      
+       vacuum_cost_page_dirty (integer)
+       
+        vacuum_cost_page_dirty configuration parameter
+       
+       
+        
+         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.
+        
+       
+      
+
+      
+       vacuum_cost_limit (integer)
+       
+        vacuum_cost_limit configuration parameter
+       
+       
+        
+         The accumulated cost that will cause the vacuuming process to sleep.
+         The default value is 200.
+        
+       
+      
+     
+
+     
+      
+       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 vacuum_cost_delay *
+       accumulated_balance /
+       vacuum_cost_limit with a maximum of
+       vacuum_cost_delay * 4.
+      
+     
+    
+
+    
+     Background Writer
+
+     
+      Beginning in PostgreSQL 8.0, there is a separate server
+      process called the background writer, whose sole function
+      is to issue writes of 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.
+     
+
+     
+      
+       bgwriter_delay (integer)
+       
+        bgwriter_delay configuration parameter
+       
+       
+        
+         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 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 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 only be set at server start or in the
+         postgresql.conf file.
+        
+       
+      
+
+      
+       bgwriter_lru_percent (floating point)
+       
+        bgwriter_lru_percent configuration parameter
+       
+       
+        
+         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
+         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 only be set at server start or in the
+         postgresql.conf file.
+        
+       
+      
+
+      
+       bgwriter_lru_maxpages (integer)
+       
+        bgwriter_lru_maxpages configuration parameter
+       
+       
+        
+         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 only be set at server start or in the
+         postgresql.conf file.
+        
+       
+      
+
+      
+       bgwriter_all_percent (floating point)
+       
+        bgwriter_all_percent configuration parameter
+       
+       
+        
+         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
+         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 bgwriter_delay
+         setting, this will allow the entire shared buffer pool to be scanned
+         about once per minute.
+         This option can only be set at server start or in the
+         postgresql.conf file.
+        
+       
+      
+
+      
+       bgwriter_all_maxpages (integer)
+       
+        bgwriter_all_maxpages configuration parameter
+       
+       
+        
+         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 only be set at server start or in the
+         postgresql.conf file.
+        
+       
+      
+     
+
+     
+      Smaller values of bgwriter_all_percent and
+      bgwriter_all_maxpages 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 bgwriter_lru_percent and
+      bgwriter_lru_maxpages 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 maxpages values and/or both
+      percent values to zero.
+     
+    
+   
+
+   
+    Write Ahead Log
+
+   
+    See also  for details on WAL
+    tuning.
+   
+
+    
+     Settings
+     
+     
+     
+      
+       fsync configuration parameter
+      
+      fsync (boolean)
+      
+       
+        If this option is on, the PostgreSQL server
+        will use the fsync() system call in several places
+        to make sure that updates are physically written to disk. This
+        insures that a database cluster will recover to a
+        consistent state after an operating system or hardware crash.
+       
+
+       
+        However, using fsync() results in a
+        performance penalty: when a transaction is committed,
+        PostgreSQL must wait for the
+        operating system to flush the write-ahead log to disk.  When
+        fsync is disabled, the operating system is
+        allowed to do its best in buffering, ordering, and delaying
+        writes. This can result in significantly improved performance.
+        However, if the system crashes, the results of the last few
+        committed transactions may be lost in part or whole. In the
+        worst case, unrecoverable data corruption may occur.
+        (Crashes of the database server itself are not
+        a risk factor here.  Only an operating-system-level crash
+        creates a risk of corruption.)
+       
+
+       
+        Due to the risks involved, there is no universally correct
+        setting for fsync. Some administrators
+        always disable fsync, while others only
+        turn it off for bulk loads, where there is a clear restart
+        point if something goes wrong, whereas some administrators
+        always leave fsync enabled. The default is
+        to enable fsync, for maximum reliability.
+        If you trust your operating system, your hardware, and your
+        utility company (or your battery backup), you can consider
+        disabling fsync.
+       
+
+       
+        This option can only be set at server start or in the
+        postgresql.conf file.  If this option
+        is off, consider also turning off 
+        guc-full-page-writes.
+       
+      
+     
+     
+     
+      wal_sync_method (string)
+      
+       wal_sync_method configuration parameter
+      
+      
+       
+        Method used for forcing WAL updates out to disk.  Possible
+        values are:
+       
+       
+        
+        
+         open_datasync (write WAL files with open() option O_DSYNC)
+        
+        
+        
+        
+         fdatasync (call fdatasync() at each commit),
+        
+        
+        
+        
+         fsync (call fsync() at each commit)
+        
+        
+        
+        
+         fsync_writethrough (force write-through of any disk write cache)
+        
+        
+        
+        
+         open_sync (write WAL files with open() option O_SYNC)
+        
+        
+       
+       
+        Not all of these choices are available on all platforms.
+        The top-most supported option is used as the default.
+        If fsync is off then this setting is irrelevant.
+        This option can only be set at server start or in the
+        postgresql.conf file.
+       
+      
+     
+     
+     
+      
+       full_page_writes configuration parameter
+      
+      full_page_writes (boolean)
+      
+       
+        A page write in process during an operating system crash might
+        be only partially written to disk, leading to an on-disk page
+        that contains a mix of old and new data. During recovery, the
+        row changes stored in WAL are not enough to completely restore
+        the page.
+       
+
+       
+        When this option is on, the PostgreSQL server
+        writes full pages to WAL when they are first modified after a
+        checkpoint so full recovery is possible. Turning this option off
+        might lead to a corrupt system after an operating system crash
+        or power failure because uncorrected partial pages might contain
+        inconsistent or corrupt data. The risks are less but similar to
+        fsync.
+       
+
+       
+        This option can only be set at server start or in the
+        postgresql.conf file.  The default is
+        on.
+       
+      
+     
+     
+     
+      wal_buffers (integer)
+      
+       wal_buffers configuration parameter
+      
+      
+       
+        Number of disk-page buffers allocated in shared memory for WAL data.
+        The default is 8.  The setting need only be large enough to hold
+        the amount of WAL data generated by one typical transaction, since
+        the data is flushed to disk at every transaction commit.
+        This option can only be set at server start.
+       
+
+       
+        Increasing this parameter may cause PostgreSQL
+        to request more System V shared
+        memory than your operating system's default configuration
+        allows. See  for information on how to
+        adjust those parameters, if necessary.
+       
+      
+     
+                
+     
+      commit_delay (integer)
+      
+       commit_delay configuration parameter
+      
+      
+       
+        Time delay between writing a commit record to the WAL buffer
+        and flushing the buffer out to disk, in microseconds. A
+        nonzero delay can allow multiple transactions to be committed
+        with only one fsync() system call, if
+        system load is high enough that additional transactions become
+        ready to commit within the given interval. But the delay is
+        just wasted if no other transactions become ready to
+        commit. Therefore, the delay is only performed if at least
+        commit_siblings other transactions are
+        active at the instant that a server process has written its
+        commit record. The default is zero (no delay).
+       
+      
+     
+
+     
+      commit_siblings (integer)
+      
+       commit_siblings configuration parameter
+      
+      
+       
+        Minimum number of concurrent open transactions to require
+        before performing the commit_delay delay. A larger
+        value makes it more probable that at least one other
+        transaction will become ready to commit during the delay
+        interval. The default is five.
+       
+      
+     
+
+     
+     
+     
+     Checkpoints
+
+    
+     
+      checkpoint_segments (integer)
+      
+       checkpoint_segments configuration parameter
+      
+      
+       
+        Maximum distance between automatic WAL checkpoints, in log
+        file segments (each segment is normally 16 megabytes). The
+        default is three.  This option can only be set at server start
+        or in the postgresql.conf file.
+       
+      
+     
+
+     
+      checkpoint_timeout (integer)
+      
+       checkpoint_timeout configuration parameter
+      
+      
+       
+        Maximum time between automatic WAL checkpoints, in
+        seconds. The default is 300 seconds.  This option can only be
+        set at server start or in the postgresql.conf
+        file.
+       
+      
+     
+
+     
+      checkpoint_warning (integer)
+      
+       checkpoint_warning configuration parameter
+      
+      
+       
+        Write a message to the server log if checkpoints caused by
+        the filling of checkpoint segment files happen closer together
+        than this many seconds.  The default is 30 seconds.
+        Zero turns off the warning.
+       
+      
+     
+
+     
+     
+     
+     Archiving
+
+    
+     
+      archive_command (string)
+      
+       archive_command configuration parameter
+      
+      
+       
+        The shell command to execute to archive a completed segment of
+        the WAL file series. If this is an empty string (the default),
+        WAL archiving is disabled. Any %p in the string is
+        replaced by the absolute path of the file to archive, and any
+        %f is replaced by the file name only. Use
+        %% to embed an actual % character in the
+        command. For more information see 
+        linkend="backup-archiving-wal">. This option can only be set at
+        server start or in the postgresql.conf
+        file.
+       
+       
+        It is important for the command to return a zero exit status if
+        and only if it succeeds.  Examples:
+
+archive_command = 'cp "%p" /mnt/server/archivedir/"%f"'
+archive_command = 'copy "%p" /mnt/server/archivedir/"%f"'  # Windows
+
+       
+      
+     
+     
+     
+    
+   
+
+   
+    Query Planning
+
+    
+     Planner Method Configuration
+
+      
+       These configuration parameters provide a crude method of
+       influencing the query plans chosen by the query optimizer. If
+       the default plan chosen by the optimizer for a particular query
+       is not optimal, a temporary solution may be found by using one
+       of these configuration parameters to force the optimizer to
+       choose a different plan.  Turning one of these settings off
+       permanently is seldom a good idea, however.
+       Better ways to improve the quality of the
+       plans chosen by the optimizer include adjusting the 
+       linkend="runtime-config-query-constants"
+       endterm="runtime-config-query-constants-title">, running 
+       linkend="sql-analyze" endterm="sql-analyze-title"> more
+       frequently, increasing the value of the 
+       linkend="guc-default-statistics-target"> configuration parameter,
+       and increasing the amount of statistics collected for
+       specific columns using ALTER TABLE SET
+       STATISTICS.
+      
+
+     
+     
+      enable_bitmapscan (boolean)
+      
+       bitmap scan
+      
+      
+       enable_bitmapscan configuration parameter
+      
+      
+       
+        Enables or disables the query planner's use of bitmap-scan plan
+        types. The default is on.
+       
+      
+     
+
+     
+      enable_hashagg (boolean)
+      
+       enable_hashagg configuration parameter
+      
+      
+       
+        Enables or disables the query planner's use of hashed
+        aggregation plan types. The default is on.
+       
+      
+     
+
+     
+      enable_hashjoin (boolean)
+      
+       enable_hashjoin configuration parameter
+      
+      
+       
+        Enables or disables the query planner's use of hash-join plan
+        types. The default is on.
+       
+      
+     
+
+     
+      enable_indexscan (boolean)
+      
+       index scan
+      
+      
+       enable_indexscan configuration parameter
+      
+      
+       
+        Enables or disables the query planner's use of index-scan plan
+        types. The default is on.
+       
+      
+     
+
+     
+      enable_mergejoin (boolean)
+      
+       enable_mergejoin configuration parameter
+      
+      
+       
+        Enables or disables the query planner's use of merge-join plan
+        types. The default is on.
+       
+      
+     
+
+     
+      enable_nestloop (boolean)
+      
+       enable_nestloop configuration parameter
+      
+      
+       
+        Enables or disables the query planner's use of nested-loop join
+        plans. It's not possible to suppress nested-loop joins entirely,
+        but turning this variable off discourages the planner from using
+        one if there are other methods available. The default is
+        on.
+       
+      
+     
+
+     
+      enable_seqscan (boolean)
+      
+       sequential scan
+      
+      
+       enable_seqscan configuration parameter
+      
+      
+       
+        Enables or disables the query planner's use of sequential scan
+        plan types. It's not possible to suppress sequential scans
+        entirely, but turning this variable off discourages the planner
+        from using one if there are other methods available. The
+        default is on.
+       
+      
+     
+
+     
+      enable_sort (boolean)
+      
+       enable_sort configuration parameter
+      
+      
+       
+        Enables or disables the query planner's use of explicit sort
+        steps. It's not possible to suppress explicit sorts entirely,
+        but turning this variable off discourages the planner from
+        using one if there are other methods available. The default
+        is on.
+       
+      
+     
+
+     
+      enable_tidscan (boolean)
+      
+       enable_tidscan configuration parameter
+      
+      
+       
+        Enables or disables the query planner's use of TID
+        scan plan types. The default is on.
+       
+      
+     
+     
+     
+     
+     
+     
+      Planner Cost Constants
+     
+
+   
+    
+     Unfortunately, there is no well-defined method for determining
+     ideal values for the family of cost variables that
+     appear below. You are encouraged to experiment and share
+     your findings.
+    
+   
+
+     
+     
+     
+      effective_cache_size (floating point)
+      
+       effective_cache_size configuration parameter
+      
+      
+       
+        Sets the planner's assumption about the effective size of the
+        disk cache that is available to a single index scan.  This is
+        factored into estimates of the cost of using an index; a higher
+        value makes it more likely index scans will be used, a lower
+        value makes it more likely sequential scans will be used. When
+        setting this parameter you should consider both
+        PostgreSQL's shared buffers and the
+        portion of the kernel's disk cache that will be used for
+        PostgreSQL data files.  Also, take into
+        account the expected number of concurrent queries using different
+        indexes, since they will have to share the available space.
+        This parameter has no effect on the size of shared memory
+        allocated by PostgreSQL, nor does it reserve kernel disk cache;
+        it is used only for estimation purposes.
+        The value is measured in disk pages, which are
+        normally 8192 bytes each. The default is 1000.
+       
+      
+     
+
+     
+      random_page_cost (floating point)
+      
+       random_page_cost configuration parameter
+      
+      
+       
+        Sets the planner's estimate of the cost of a
+        nonsequentially fetched disk page. This is measured as a
+        multiple of the cost of a sequential page fetch. A higher
+        value makes it more likely a sequential scan will be used, a
+        lower value makes it more likely an index scan will be
+        used. The default is four.
+       
+      
+     
+
+     
+      cpu_tuple_cost (floating point)
+      
+       cpu_tuple_cost configuration parameter
+      
+      
+       
+        Sets the planner's estimate of the cost of processing
+        each row during a query. This is measured as a fraction of
+        the cost of a sequential page fetch. The default is 0.01.
+       
+      
+     
+
+     
+      cpu_index_tuple_cost (floating point)
+      
+       cpu_index_tuple_cost configuration parameter
+      
+      
+       
+        Sets the planner's estimate of the cost of processing
+        each index row during an index scan. This is measured as a
+        fraction of the cost of a sequential page fetch. The default
+        is 0.001.
+       
+      
+     
+    
+     
+      cpu_operator_cost (floating point)
+      
+       cpu_operator_cost configuration parameter
+      
+      
+       
+        Sets the planner's estimate of the cost of processing each
+        operator in a WHERE clause. This is measured as a fraction of
+        the cost of a sequential page fetch. The default is 0.0025.
+       
+      
+     
+
+     
+
+    
+     
+     Genetic Query Optimizer
+
+     
+
+     
+      
+       genetic query optimization
+      
+      
+       GEQO
+       genetic query optimization
+      
+      
+       geqo configuration parameter
+      
+      geqo (boolean)
+      
+       
+        Enables or disables genetic query optimization, which is an
+        algorithm that attempts to do query planning without
+        exhaustive searching. This is on by default. The
+        geqo_threshold variable provides a more
+        granular way to disable GEQO for certain classes of queries.
+       
+      
+     
+
+     
+      geqo_threshold (integer)
+      
+       geqo_threshold configuration parameter
+      
+      
+       
+        Use genetic query optimization to plan queries with at least
+        this many FROM items involved. (Note that an outer
+        JOIN construct counts as only one FROM
+        item.) The default is 12. For simpler queries it is usually best
+        to use the deterministic, exhaustive planner, but for queries with
+        many tables the deterministic planner takes too long.
+       
+      
+     
+
+     
+      geqo_effort
+      (integer)
+      
+       geqo_effort configuration parameter
+      
+      
+       
+        Controls the trade off between planning time and query plan
+        efficiency in GEQO. This variable must be an integer in the
+        range from 1 to 10. The default value is 5. Larger values
+        increase the time spent doing query planning, but also
+        increase the likelihood that an efficient query plan will be
+        chosen.
+       
+
+       
+        geqo_effort doesn't actually do anything
+        directly; it is only used to compute the default values for
+        the other variables that influence GEQO behavior (described
+        below). If you prefer, you can set the other parameters by
+        hand instead.
+       
+      
+     
+
+     
+      geqo_pool_size (integer)
+      
+       geqo_pool_size configuration parameter
+      
+      
+       
+        Controls the pool size used by GEQO. The pool size is the
+        number of individuals in the genetic population.  It must be
+        at least two, and useful values are typically 100 to 1000.  If
+        it is set to zero (the default setting) then a suitable
+        default is chosen based on geqo_effort and
+        the number of tables in the query.
+       
+      
+     
+
+     
+      geqo_generations (integer)
+      
+       geqo_generations configuration parameter
+      
+      
+       
+        Controls the number of generations used by GEQO.  Generations
+        specifies the number of iterations of the algorithm.  It must
+        be at least one, and useful values are in the same range as
+        the pool size.  If it is set to zero (the default setting)
+        then a suitable default is chosen based on
+        geqo_pool_size.
+       
+      
+     
+
+     
+      geqo_selection_bias (floating point)
+      
+       geqo_selection_bias configuration parameter
+      
+      
+       
+        Controls the selection bias used by GEQO. The selection bias
+        is the selective pressure within the population. Values can be
+        from 1.50 to 2.00; the latter is the default.
+       
+      
+     
+     
+     
+    
+     
+     Other Planner Options
+
+     
+
+     
+      default_statistics_target (integer)
+      
+       default_statistics_target configuration parameter
+      
+      
+       
+        Sets the default statistics target for table columns that have
+        not had a column-specific target set via ALTER TABLE
+        SET STATISTICS.  Larger values increase the time needed to
+        do ANALYZE, but may improve the quality of the
+        planner's estimates. The default is 10. For more information
+        on the use of statistics by the PostgreSQL
+        query planner, refer to .
+       
+      
+     
+
+     
+      constraint_exclusion (boolean)
+      
+       constraint exclusion
+      
+      
+       constraint_exclusion configuration parameter
+      
+      
+       
+        Enables or disables the query planner's use of table constraints to
+        limit table access.  The default is off.
+       
+
+       
+        When this parameter is on, the planner compares query
+        conditions with table CHECK constraints, and omits scanning tables
+        where the conditions contradict the constraints.  (Presently
+        this is done only for child tables of inheritance scans.)  For
+        example:
+
+
+CREATE TABLE parent(key integer, ...);
+CREATE TABLE child1000(check (key between 1000 and 1999)) INHERITS(parent);
+CREATE TABLE child2000(check (key between 2000 and 2999)) INHERITS(parent);
+...
+SELECT * FROM parent WHERE key = 2400;
+
+
+        With constraint exclusion enabled, this SELECT will not scan
+        child1000 at all.  This can improve performance when
+        inheritance is used to build partitioned tables.
+       
+
+       
+        Currently, constraint_exclusion defaults to
+        off, because it risks incorrect results if
+        query plans are cached --- if a table constraint is changed or dropped,
+        the previously generated plan might now be wrong, and there is no
+        built-in mechanism to force re-planning.  (This deficiency will
+        probably be addressed in a future
+        PostgreSQL release.)  Another reason
+        for keeping it off is that the constraint checks are relatively
+        expensive, and in many circumstances will yield no savings.
+        It is recommended to turn this on only if you are actually using
+        partitioned tables designed to take advantage of the feature.
+       
+      
+     
+
+     
+      from_collapse_limit (integer)
+      
+       from_collapse_limit configuration parameter
+      
+      
+       
+        The planner will merge sub-queries into upper queries if the
+        resulting FROM list would have no more than
+        this many items.  Smaller values reduce planning time but may
+        yield inferior query plans.  The default is 8.  It is usually
+        wise to keep this less than .
+       
+      
+     
+
+     
+      join_collapse_limit (integer)
+      
+       join_collapse_limit configuration parameter
+      
+      
+       
+        The planner will rewrite explicit inner JOIN
+        constructs into lists of FROM items whenever a
+        list of no more than this many items in total would
+        result. Prior to PostgreSQL 7.4, joins
+        specified via the JOIN construct would
+        never be reordered by the query planner. The query planner has
+        subsequently been improved so that inner joins written in this
+        form can be reordered; this configuration parameter controls
+        the extent to which this reordering is performed.
+        
+         
+          At present, the order of outer joins specified via the
+          JOIN construct is never adjusted by the query
+          planner; therefore, join_collapse_limit has no
+          effect on this behavior. The planner may be improved to
+          reorder some classes of outer joins in a future release of
+          PostgreSQL.
+         
+        
+       
+
+       
+        By default, this variable is set the same as
+        from_collapse_limit, which is appropriate
+        for most uses. Setting it to 1 prevents any reordering of
+        inner JOINs. Thus, the explicit join order
+        specified in the query will be the actual order in which the
+        relations are joined. The query planner does not always choose
+        the optimal join order; advanced users may elect to
+        temporarily set this variable to 1, and then specify the join
+        order they desire explicitly. Another consequence of setting
+        this variable to 1 is that the query planner will behave more
+        like the PostgreSQL 7.3 query
+        planner, which some users might find useful for backward
+        compatibility reasons.
+       
+
+       
+        Setting this variable to a value between 1 and
+        from_collapse_limit might be useful to
+        trade off planning time against the quality of the chosen plan
+        (higher values produce better plans).
+       
+      
+     
+     
+     
+    
+   
+
+   
+    Error Reporting and Logging
+
+    
+     server log
+    
+
+    
+     Where to log
+
+     
+      where to log
+     
+
+     
+
+     
+      log_destination (string)
+      
+       log_destination configuration parameter
+      
+      
+       
+        PostgreSQL supports several methods
+         for logging server messages, including
+         stderr and
+         syslog. On Windows, 
+         eventlog is also supported. Set this
+         option to a list of desired log destinations separated by
+         commas. The default is to log to stderr 
+         only.
+         This option can only be set at server start or in the
+         postgresql.conf configuration file.
+       
+      
+     
+
+     
+      redirect_stderr (boolean)
+      
+       redirect_stderr configuration parameter
+      
+      
+       
+         This option allows messages sent to stderr to be
+         captured and redirected into log files.
+         This option, in combination with logging to stderr,
+         is often more useful than
+         logging to syslog, since some types of messages
+         may not appear in syslog output (a common example
+         is dynamic-linker failure messages).
+         This option can only be set at server start.
+       
+      
+     
+
+     
+      log_directory (string)
+      
+       log_directory configuration parameter
+      
+      
+       
+        When redirect_stderr is enabled, this option
+        determines the directory in which log files will be created.
+        It may be specified as an absolute path, or relative to the
+        cluster data directory.
+        This option can only be set at server start or in the
+        postgresql.conf configuration file.
+       
+      
+     
+
+     
+      log_filename (string)
+      
+       log_filename configuration parameter
+      
+      
+       
+        When redirect_stderr is enabled, this option
+        sets the file names of the created log files.  The value
+        is treated as a strftime pattern,
+        so %-escapes
+        can be used to specify time-varying file names.
+        If no %-escapes are present,
+        PostgreSQL will
+        append the epoch of the new log file's open time.  For example,
+        if log_filename were server_log, then the
+        chosen file name would be server_log.1093827753
+        for a log starting at Sun Aug 29 19:02:33 2004 MST.
+        This option can only be set at server start or in the
+        postgresql.conf configuration file.
+       
+      
+     
+
+     
+      log_rotation_age (integer)
+      
+       log_rotation_age configuration parameter
+      
+      
+       
+        When redirect_stderr is enabled, this option
+        determines the maximum lifetime of an individual log file.
+        After this many minutes have elapsed, a new log file will
+        be created.  Set to zero to disable time-based creation of
+        new log files.
+        This option can only be set at server start or in the
+        postgresql.conf configuration file.
+       
+      
+     
+
+     
+      log_rotation_size (integer)
+      
+       log_rotation_size configuration parameter
+      
+      
+       
+        When redirect_stderr is enabled, this option
+        determines the maximum size of an individual log file.
+        After this many kilobytes have been emitted into a log file,
+        a new log file will be created.  Set to zero to disable size-based
+        creation of new log files.
+        This option can only be set at server start or in the
+        postgresql.conf configuration file.
+       
+      
+     
+
+     
+      log_truncate_on_rotation (boolean)
+      
+       log_truncate_on_rotation configuration parameter
+      
+      
+       
+        When redirect_stderr is enabled, this option will cause
+        PostgreSQL to truncate (overwrite),
+        rather than append to, any existing log file of the same name.
+        However, truncation will occur only when a new file is being opened
+        due to time-based rotation, not during server startup or size-based
+        rotation.  When off, pre-existing files will be appended to in
+        all cases.  For example, using this option in combination with
+        a log_filename like postgresql-%H.log
+        would result in generating twenty-four hourly log files and then
+        cyclically overwriting them.
+        This option can only be set at server start or in the
+        postgresql.conf configuration file.
+       
+       
+        Example:  To keep 7 days of logs, one log file per day named
+        server_log.Mon, server_log.Tue, 
+        etc, and automatically overwrite last week's log with this week's log,
+        set log_filename to server_log.%a, 
+        log_truncate_on_rotation to on, and 
+        log_rotation_age to 1440.
+       
+       
+        Example: To keep 24 hours of logs, one log file per hour, but 
+        also rotate sooner if the log file size exceeds 1GB, set 
+        log_filename to server_log.%H%M, 
+        log_truncate_on_rotation to on, 
+        log_rotation_age to 60, and 
+        log_rotation_size to 1000000.
+        Including %M in log_filename allows
+        any size-driven rotations that may occur to select a filename
+        different from the hour's initial filename.
+       
+      
+     
+
+     
+      syslog_facility (string)
+      
+       syslog_facility configuration parameter
+      
+      
+       
+        When logging to syslog is enabled, this option
+        determines the syslog
+        facility to be used.  You may choose
+        from LOCAL0, LOCAL1,
+        LOCAL2, LOCAL3, LOCAL4,
+        LOCAL5, LOCAL6, LOCAL7;
+        the default is LOCAL0. See also the
+        documentation of your system's
+        syslog daemon.
+        This option can only be set at server start.
+       
+      
+     
+     
+     
+      syslog_ident (string)
+      
+       syslog_identity configuration parameter
+      
+       
+        
+         When logging to syslog is enabled, this option
+         determines the program name used to identify
+         PostgreSQL messages in
+         syslog logs. The default is
+         postgres.
+          This option can only be set at server start.
+        
+       
+      
+      
+      
+    
+     
+     When To Log
+
+     
+
+     
+      client_min_messages (string)
+      
+       client_min_messages configuration parameter
+      
+      
+       
+        Controls which message levels are sent to the client.
+        Valid values are DEBUG5,
+        DEBUG4, DEBUG3, DEBUG2,
+        DEBUG1, LOG, NOTICE,
+        WARNING, and ERROR.  Each level
+        includes all the levels that follow it.  The later the level,
+        the fewer messages are sent.  The default is
+        NOTICE.  Note that LOG has a different
+        rank here than in log_min_messages.
+       
+      
+     
+
+     
+      log_min_messages (string)
+      
+       log_min_messages configuration parameter
+      
+      
+       
+        Controls which message levels are written to the server log.
+        Valid values are DEBUG5, DEBUG4,
+        DEBUG3, DEBUG2, DEBUG1,
+        INFO, NOTICE, WARNING,
+        ERROR, LOG, FATAL, and
+        PANIC.  Each level includes all the levels that
+        follow it.  The later the level, the fewer messages are sent
+        to the log.  The default is NOTICE.  Note that
+        LOG has a different rank here than in
+        client_min_messages.
+        Only superusers can change this setting.
+       
+      
+     
+
+     
+      log_error_verbosity (string)
+      
+       log_error_verbosity configuration parameter
+      
+      
+       
+        Controls the amount of detail written in the server log for each
+        message that is logged.  Valid values are TERSE,
+        DEFAULT, and VERBOSE, each adding more
+        fields to displayed messages.
+        Only superusers can change this setting.
+       
+      
+     
+
+     
+      log_min_error_statement (string)
+      
+       log_min_error_statement configuration parameter
+      
+      
+       
+        Controls whether or not the SQL statement that causes an error
+        condition will also be recorded in the server log. All SQL
+        statements that cause an error of the specified level or
+        higher are logged.  The default is
+        PANIC (effectively turning this feature
+        off for normal use). Valid values are DEBUG5,
+        DEBUG4, DEBUG3,
+        DEBUG2, DEBUG1,
+        INFO, NOTICE,
+        WARNING, ERROR,
+        FATAL, and PANIC.  For
+        example, if you set this to ERROR then all
+        SQL statements causing errors, fatal errors, or panics will be
+        logged. Enabling this option can be helpful in tracking down
+        the source of any errors that appear in the server log.
+        Only superusers can change this setting.
+       
+      
+     
+     
+     
+      log_min_duration_statement (integer)
+      
+       log_min_duration_statement configuration parameter
+      
+       
+        
+         Logs the statement and its duration on a single log line if its
+         duration is greater than or equal to the specified number of
+         milliseconds. Setting this to zero will print all statements
+         and their durations. Minus-one (the default) disables the
+         feature. For example, if you set it to 250
+         then all SQL statements that run 250ms or longer will be
+         logged. Enabling this option can be useful in tracking down
+         unoptimized queries in your applications. This setting is
+         independent of log_statement and
+         log_duration. Only superusers can change
+         this setting.
+        
+       
+      
+
+     
+      silent_mode (boolean)
+      
+       silent_mode configuration parameter
+      
+      
+       
+        Runs the server silently. If this option is set, the server
+        will automatically run in background and any controlling
+        terminals are disassociated (same effect as
+        postmaster's -S option).
+        The server's standard output and standard error are redirected
+        to /dev/null, so any messages sent to them will be lost.
+        Unless syslog logging is selected or
+        redirect_stderr is enabled, using this option
+        is discouraged because it makes it impossible to see error messages.
+       
+      
+     
+
+     
+
+       
+        Here is a list of the various message severity levels used in
+        these settings:
+        
+         
+          DEBUG[1-5]
+          
+           
+            Provides information for use by developers.
+           
+          
+         
+
+         
+          INFO
+          
+           
+            Provides information implicitly requested by the user,
+            e.g., during VACUUM VERBOSE.
+           
+          
+         
+
+         
+          NOTICE
+          
+           
+            Provides information that may be helpful to users, e.g.,
+            truncation of long identifiers and the creation of indexes as part
+            of primary keys.
+           
+          
+         
+
+         
+          WARNING
+          
+           
+            Provides warnings to the user, e.g., COMMIT
+            outside a transaction block.
+           
+          
+         
+
+         
+          ERROR
+          
+           
+            Reports an error that caused the current command to abort.
+           
+          
+         
+
+         
+          LOG
+          
+           
+            Reports information of interest to administrators, e.g.,
+            checkpoint activity.
+           
+          
+         
+
+         
+          FATAL
+          
+           
+            Reports an error that caused the current session to abort.
+           
+          
+         
+
+         
+          PANIC
+          
+           
+            Reports an error that caused all sessions to abort.
+           
+          
+         
+        
+       
+
+    
+     
+     What To Log
+
+     
+
+     
+      debug_print_parse (boolean)
+      debug_print_rewritten (boolean)
+      debug_print_plan (boolean)
+      debug_pretty_print (boolean)
+      
+       debug_print_parse configuration parameter
+      
+      
+       debug_print_rewritten configuration parameter
+      
+      
+       debug_print_plan configuration parameter
+      
+      
+       debug_pretty_print configuration parameter
+      
+      
+       
+        These options enable various debugging output to be emitted.
+        For each executed query, they print
+        the resulting parse tree, the query rewriter output, or the
+        execution plan.  debug_pretty_print indents
+        these displays to produce a more readable but much longer
+        output format.  client_min_messages or
+        log_min_messages must be
+        DEBUG1 or lower to actually send this output
+        to the client or the server log, respectively.
+        These options are off by default.
+       
+      
+     
+
+     
+      log_connections (boolean)
+      
+       log_connections configuration parameter
+      
+      
+       
+        This outputs a line to the server log detailing each successful
+        connection. This is off by default, although it is probably very
+        useful. This option can only be set at server start or in the
+        postgresql.conf configuration file.
+       
+      
+     
+
+     
+      log_disconnections (boolean)
+      
+       log_disconnections configuration parameter
+      
+      
+       
+        This outputs a line in the server log similar to
+        log_connections but at session termination,
+        and includes the duration of the session.  This is off by
+        default. This option can only be set at server start or in the
+        postgresql.conf configuration file.
+       
+      
+     
+
+
+     
+      log_duration (boolean)
+      
+       log_duration configuration parameter
+      
+      
+       
+        Causes the duration of every completed statement which satisfies
+        log_statement to be logged.  When using this option, 
+        if you are not using syslog, it is recommended 
+        that you log the PID or session ID using log_line_prefix 
+        so that you can link the statement to the 
+        duration using the process ID or session ID. The default is
+        off. Only superusers can change this setting.
+       
+      
+     
+     
+     
+      log_line_prefix (string)
+      
+       log_line_prefix configuration parameter
+      
+      
+       
+         This is a printf-style string that is output at the
+         beginning of each log line. The default is an empty string.
+         Each recognized escape is replaced as outlined 
+         below - anything else that looks like an escape is ignored. Other
+         characters are copied straight to the log line. Some escapes are
+         only recognised by session processes, and do not apply to
+         background processes such as the postmaster. Syslog
+         produces its own 
+         time stamp and process ID information, so you probably do not want to
+         use those escapes if you are using syslog.
+         This option can only be set at server start or in the
+         postgresql.conf configuration file.
+
+         
+          
+           
+            
+             Escape
+             Effect
+             Session only
+             
+            
+           
+            
+             %u
+             User name
+             yes
+            
+            
+             %d
+             Database name
+             yes
+            
+            
+             %r
+             Remote host name or IP address, and remote port
+             yes
+            
+            
+             %h
+             Remote Hostname or IP address
+             yes
+            
+            
+             %p
+             Process ID
+             no
+            
+            
+             %t
+             Time stamp (no milliseconds)
+             no
+            
+            
+             %m
+             Time stamp with milliseconds
+             no
+            
+            
+             %i
+             Command tag: This is the command that generated the log line.
+             yes
+            
+            
+             %c
+             Session ID: A unique identifier for each session.
+             It is 2 4-byte hexadecimal numbers (without leading zeros) 
+             separated by a dot. The numbers
+             are the session start time and the process ID, so this can also
+             be used as a space saving way of printing these items.
+             yes
+            
+            
+             %l
+             Number of the log line for each process, starting at 1
+             no
+            
+            
+             %s
+             Session start time stamp
+             yes
+            
+            
+             %x
+             Transaction ID
+             yes
+            
+            
+             %q
+             Does not produce any output, but tells non-session
+             processes to stop at this point in the string. Ignored by
+             session processes.
+             no
+            
+            
+             %%
+             Literal %
+             no
+            
+           
+          
+         
+       
+      
+     
+
+     
+      log_statement (string)
+      
+       log_statement configuration parameter
+      
+      
+       
+        Controls which SQL statements are logged. Valid values are
+        none, ddl, mod, and
+        all. ddl logs all data definition
+        commands like CREATE, ALTER, and
+        DROP commands. mod logs all
+        ddl statements, plus INSERT,
+        UPDATE, DELETE, TRUNCATE,
+        and COPY FROM. PREPARE and
+        EXPLAIN ANALYZE statements are also logged if their
+        contained command is of an appropriate type.
+       
+       
+        The default is none. Only superusers can change this
+        setting.
+       
+
+       
+        
+         The EXECUTE statement is not considered a
+         ddl or mod statement.  When it is logged, 
+         only the name of the prepared statement is reported, not the
+         actual prepared statement.
+        
+
+        
+         When a function is defined in the
+         PL/pgSQLserver-side language, any queries
+         executed by the function will only be logged the first time that the
+         function is invoked in a particular session. This is because
+         PL/pgSQL keeps a cache of the
+         query plans produced for the SQL statements in the function.
+        
+       
+      
+     
+
+     
+      log_hostname (boolean)
+      
+       log_hostname configuration parameter
+      
+      
+       
+        By default, connection log messages only show the IP address of the
+        connecting host. Turning on this option causes logging of the
+        host name as well.  Note that depending on your host name resolution
+        setup this might impose a non-negligible performance penalty. This
+        option can only be set at server start or in the
+        postgresql.conf file.
+       
+      
+     
+
+     
+    
+   
+
+   
+    Runtime Statistics
+
+    
+     Statistics Monitoring
+     
+
+     
+      log_statement_stats (boolean)
+      log_parser_stats (boolean)
+      log_planner_stats (boolean)
+      log_executor_stats (boolean)
+      
+       log_statement_stats configuration parameter
+      
+      
+       log_parser_stats configuration parameter
+      
+      
+       log_planner_stats configuration parameter
+      
+      
+       log_executor_stats configuration parameter
+      
+      
+       
+        For each query, write performance statistics of the respective
+        module to the server log. This is a crude profiling
+        instrument.  log_statement_stats reports total
+        statement statistics, while the others report per-module statistics.
+        log_statement_stats cannot be enabled together with
+        any of the per-module options.  All of these options are disabled by
+        default.   Only superusers can change these settings.
+       
+      
+     
+
+     
+
+    
+    
+     Query and Index Statistics Collector
+     
+
+     
+      stats_start_collector (boolean)
+      
+       stats_start_collector configuration parameter
+      
+      
+       
+        Controls whether the server should start the
+        statistics-collection subprocess.  This is on by default, but
+        may be turned off if you know you have no interest in
+        collecting statistics.  This option can only be set at server
+        start.
+       
+      
+     
+
+     
+      stats_command_string (boolean)
+      
+       stats_command_string configuration parameter
+      
+      
+       
+        Enables the collection of statistics on the currently
+        executing command of each session, along with the time at
+        which that command began execution. This option is off by
+        default. Note that even when enabled, this information is not
+        visible to all users, only to superusers and the user owning
+        the session being reported on; so it should not represent a
+        security risk. This data can be accessed via the
+        pg_stat_activity system view; refer
+        to  for more information.
+       
+      
+     
+
+     
+      stats_block_level (boolean)
+      
+       stats_block_level configuration parameter
+      
+      
+       
+        Enables the collection of block-level statistics on database
+        activity. This option is disabled by default. If this option
+        is enabled, the data that is produced can be accessed via the
+        pg_stat and
+        pg_statio family of system views;
+        refer to  for more information.
+       
+      
+     
+
+     
+      stats_row_level (boolean)
+      
+       stats_row_level configuration parameter
+      
+      
+       
+        Enables the collection of row-level statistics on database
+        activity. This option is disabled by default. If this option
+        is enabled, the data that is produced can be accessed via the
+        pg_stat and
+        pg_statio family of system views;
+        refer to  for more information.
+       
+      
+     
+
+     
+      stats_reset_on_server_start (boolean)
+      
+       stats_reset_on_server_start configuration parameter
+      
+      
+       
+        If on, collected statistics are zeroed out whenever the server
+        is restarted. If off, statistics are accumulated across server
+        restarts. The default is off. This option can only 
+        be set at server start.
+       
+      
+     
+
+     
+    
+   
+
+   
+    Automatic Vacuuming
+
+     
+      Beginning in PostgreSQL 8.1, there is an optional server
+      process called the autovacuum daemon, whose purpose is
+      to automate the issuance of periodic VACUUM and
+      ANALYZE commands.  When enabled, the autovacuum daemon
+      runs periodically and checks for tables that have had a large number
+      of updated or deleted tuples.  This check uses the row-level statistics
+      collection facility; therefore, the autovacuum daemon cannot be used
+      unless  and
+       are set TRUE.  Also, it's
+      important to allow a slot for the autovacuum process when choosing
+      the value of .
+     
+
+    
+
+     
+      autovacuum (boolean)
+      
+       autovacuum configuration parameter
+      
+      
+       
+        Controls whether the server should start the
+        autovacuum subprocess.  This is off by default.
+        This option can only be set at server start or in the
+        postgresql.conf file.
+       
+      
+     
+
+     
+      autovacuum_naptime (integer)
+      
+       autovacuum_naptime configuration parameter
+      
+      
+       
+        Specifies the delay between activity rounds for the autovacuum
+        subprocess.  In each round the subprocess examines one database
+        and issues VACUUM and ANALYZE commands
+        as needed for tables in that database.  The delay is measured
+        in seconds, and the default is 60.
+        This option can only be set at server start or in the
+        postgresql.conf file.
+       
+      
+     
+
+     
+      autovacuum_vacuum_threshold (integer)
+      
+       autovacuum_vacuum_threshold configuration parameter
+      
+      
+       
+        Specifies the minimum number of updated or deleted tuples needed
+        to trigger a VACUUM in any one table.
+        The default is 1000.
+        This option can only be set at server start or in the
+        postgresql.conf file.
+       
+      
+     
+
+     
+      autovacuum_analyze_threshold (integer)
+      
+       autovacuum_analyze_threshold configuration parameter
+      
+      
+       
+        Specifies the minimum number of inserted, updated or deleted tuples
+        needed to trigger an ANALYZE in any one table.
+        The default is 500.
+        This option can only be set at server start or in the
+        postgresql.conf file.
+       
+      
+     
+
+     
+      autovacuum_vacuum_scale_factor (floating point)
+      
+       autovacuum_vacuum_scale_factor configuration parameter
+      
+      
+       
+        Specifies a fraction of the table size to add to
+        autovacuum_vacuum_threshold
+        when deciding whether to trigger a VACUUM.
+        The default is 0.4.
+        This option can only be set at server start or in the
+        postgresql.conf file.
+       
+      
+     
+
+     
+      autovacuum_analyze_scale_factor (floating point)
+      
+       autovacuum_analyze_scale_factor configuration parameter
+      
+      
+       
+        Specifies a fraction of the table size to add to
+        autovacuum_analyze_threshold
+        when deciding whether to trigger an ANALYZE.
+        The default is 0.2.
+        This option can only be set at server start or in the
+        postgresql.conf file.
+       
+      
+     
+
+     
+      autovacuum_vacuum_cost_delay (integer)
+      
+       autovacuum_vacuum_cost_delay configuration parameter
+      
+      
+       
+        Specifies the cost delay value that will be used in automatic
+        VACUUM operations.  If -1 is specified (which is the
+        default), the regular
+         value will be used.
+        This setting can be overridden for individual tables by entries in
+        pg_autovacuum.
+       
+      
+     
+
+     
+      autovacuum_vacuum_cost_limit (integer)
+      
+       autovacuum_vacuum_cost_limit configuration parameter
+      
+      
+       
+        Specifies the cost limit value that will be used in automatic
+        VACUUM operations.  If -1 is specified (which is the
+        default), the regular
+         value will be used.
+        This setting can be overridden for individual tables by entries in
+        pg_autovacuum.
+       
+      
+     
+
+    
+   
+
+   
+    Client Connection Defaults
+
+    
+     Statement Behavior
+     
+
+     
+      search_path (string)
+      
+       search_path configuration parameter
+      
+      pathfor schemas
+      
+       
+        This variable specifies the order in which schemas are searched
+        when an object (table, data type, function, etc.) is referenced by a
+        simple name with no schema component.  When there are objects of
+        identical names in different schemas, the one found first
+        in the search path is used.  An object that is not in any of the
+        schemas in the search path can only be referenced by specifying
+        its containing schema with a qualified (dotted) name.
+       
+
+       
+        The value for search_path has to be a comma-separated
+        list of schema names.  If one of the list items is
+        the special value $user, then the schema
+        having the name returned by SESSION_USER is substituted, if there
+        is such a schema.  (If not, $user is ignored.)
+       
+
+       
+        The system catalog schema, pg_catalog, is always
+        searched, whether it is mentioned in the path or not.  If it is
+        mentioned in the path then it will be searched in the specified
+        order.  If pg_catalog is not in the path then it will
+        be searched before searching any of the path items.
+        It should also be noted that the temporary-table schema,
+        pg_temp_nnn, is implicitly searched before any of
+        these.
+       
+
+       
+        When objects are created without specifying a particular target
+        schema, they will be placed in the first schema listed
+        in the search path.  An error is reported if the search path is
+        empty.
+       
+
+       
+        The default value for this parameter is
+        '$user, public' (where the second part will be
+        ignored if there is no schema named public).
+        This supports shared use of a database (where no users
+        have private schemas, and all share use of public),
+        private per-user schemas, and combinations of these.  Other
+        effects can be obtained by altering the default search path
+        setting, either globally or per-user.
+       
+
+       
+        The current effective value of the search path can be examined
+        via the SQL function
+        current_schemas().  This is not quite the same as
+        examining the value of search_path, since
+        current_schemas() shows how the requests
+        appearing in search_path were resolved.
+       
+
+       
+        For more information on schema handling, see .
+       
+      
+     
+
+     
+      default_tablespace (string)
+      
+       default_tablespace configuration parameter
+      
+      tablespacedefault
+      
+       
+        This variable specifies the default tablespace in which to create
+        objects (tables and indexes) when a CREATE command does
+        not explicitly specify a tablespace.
+       
+
+       
+        The value is either the name of a tablespace, or an empty string
+        to specify using the default tablespace of the current database.
+        If the value does not match the name of any existing tablespace,
+        PostgreSQL will automatically use the default
+        tablespace of the current database.
+       
+
+       
+        For more information on tablespaces,
+        see .
+       
+      
+     
+
+     
+      check_function_bodies (boolean)
+      
+       check_function_bodies configuration parameter
+      
+      
+       
+        This parameter is normally on. When set to off, it
+        disables validation of the function body string during 
+        linkend="sql-createfunction"
+        endterm="sql-createfunction-title">. Disabling validation is
+        occasionally useful to avoid problems such as forward references
+        when restoring function definitions from a dump.
+       
+      
+     
+
+     
+      
+       transaction isolation level
+      
+      
+       default_transaction_isolation configuration parameter
+      
+      default_transaction_isolation (string)
+      
+       
+        Each SQL transaction has an isolation level, which can be
+        either read uncommitted, read
+        committed, repeatable read, or
+        serializable.  This parameter controls the
+        default isolation level of each new transaction. The default
+        is read committed.
+       
+
+       
+        Consult  and 
+        linkend="sql-set-transaction"
+        endterm="sql-set-transaction-title"> for more information.
+       
+      
+     
+
+     
+      
+       read-only transaction
+      
+      
+       default_transaction_read_only configuration parameter
+      
+
+      default_transaction_read_only (boolean)
+      
+       
+        A read-only SQL transaction cannot alter non-temporary tables.
+        This parameter controls the default read-only status of each new
+        transaction. The default is off (read/write).
+       
+
+       
+        Consult 
+        endterm="sql-set-transaction-title"> for more information.
+       
+      
+     
+     
+     
+      statement_timeout (integer)
+      
+       statement_timeout configuration parameter
+      
+      
+       
+        Abort any statement that takes over the specified number of
+        milliseconds.  A value of zero (the default) turns off the limitation.
+       
+      
+     
+     
+     
+    
+     
+     Locale and Formatting
+
+     
+
+     
+      DateStyle (string)
+      
+       DateStyle configuration parameter
+      
+      
+       
+        Sets the display format for date and time values, as well as the
+        rules for interpreting ambiguous date input values. For
+        historical reasons, this variable contains two independent
+        components: the output format specification (ISO,
+        Postgres, SQL, or German)
+        and the input/output specification for year/month/day ordering
+        (DMY, MDY, or YMD). These
+        can be set separately or together. The keywords Euro
+        and European are synonyms for DMY; the
+        keywords US, NonEuro, and
+        NonEuropean are synonyms for MDY. See
+         for more information. The
+        default is ISO, MDY.
+       
+      
+     
+
+     
+      timezone (string)
+      
+       timezone configuration parameter
+      
+      time zone
+      
+       
+        Sets the time zone for displaying and interpreting time
+        stamps.  The default is 'unknown', which means to use whatever 
+        the system environment specifies as the time zone.  See 
+        linkend="datatype-datetime"> for more information.
+       
+      
+     
+
+     
+      australian_timezones (boolean)
+      
+       australian_timezones configuration parameter
+      
+      time zoneAustralian
+      
+       
+        If set to on, ACST,
+        CST, EST, and
+        SAT are interpreted as Australian time
+        zones rather than as North/South American time zones and
+        Saturday. The default is off.
+       
+      
+     
+
+     
+      
+       significant digits
+      
+      
+       floating-point
+       display
+      
+      
+       extra_float_digits configuration parameter
+      
+
+      extra_float_digits (integer)
+      
+       
+        This parameter adjusts the number of digits displayed for
+        floating-point values, including float4, float8,
+        and geometric data types.  The parameter value is added to the
+        standard number of digits (FLT_DIG or DBL_DIG
+        as appropriate).  The value can be set as high as 2, to include
+        partially-significant digits; this is especially useful for dumping
+        float data that needs to be restored exactly.  Or it can be set
+        negative to suppress unwanted digits.
+       
+      
+     
+
+     
+      client_encoding (string)
+      
+       client_encoding configuration parameter
+      
+      character set
+      
+       
+        Sets the client-side encoding (character set).
+        The default is to use the database encoding.
+       
+      
+     
+
+     
+      lc_messages (string)
+      
+       lc_messages configuration parameter
+      
+      
+       
+        Sets the language in which messages are displayed.  Acceptable
+        values are system-dependent; see  for
+        more information.  If this variable is set to the empty string
+        (which is the default) then the value is inherited from the
+        execution environment of the server in a system-dependent way.
+       
+
+       
+        On some systems, this locale category does not exist.  Setting
+        this variable will still work, but there will be no effect.
+        Also, there is a chance that no translated messages for the
+        desired language exist.  In that case you will continue to see
+        the English messages.
+       
+      
+     
+
+     
+      lc_monetary (string)
+      
+       lc_monetary configuration parameter
+      
+      
+       
+        Sets the locale to use for formatting monetary amounts, for
+        example with the to_char family of
+        functions.  Acceptable values are system-dependent; see 
+        linkend="locale"> for more information.  If this variable is
+        set to the empty string (which is the default) then the value
+        is inherited from the execution environment of the server in a
+        system-dependent way.
+       
+      
+     
+
+     
+      lc_numeric (string)
+      
+       lc_numeric configuration parameter
+      
+      
+       
+        Sets the locale to use for formatting numbers, for example
+        with the to_char family of
+        functions. Acceptable values are system-dependent; see 
+        linkend="locale"> for more information.  If this variable is
+        set to the empty string (which is the default) then the value
+        is inherited from the execution environment of the server in a
+        system-dependent way.
+       
+      
+     
+
+     
+      lc_time (string)
+      
+       lc_time configuration parameter
+      
+      
+       
+        Sets the locale to use for formatting date and time values.
+        (Currently, this setting does nothing, but it may in the
+        future.)  Acceptable values are system-dependent; see 
+        linkend="locale"> for more information.  If this variable is
+        set to the empty string (which is the default) then the value
+        is inherited from the execution environment of the server in a
+        system-dependent way.
+       
+      
+     
+
+     
+
+    
+     
+     Other Defaults
+
+     
+
+     
+      explain_pretty_print (boolean)
+      
+       explain_pretty_print configuration parameter
+      
+      
+       
+        Determines whether EXPLAIN VERBOSE uses the
+        indented or non-indented format for displaying detailed
+        query-tree dumps. The default is on.
+       
+      
+     
+
+     
+      dynamic_library_path (string)
+      
+       dynamic_library_path configuration parameter
+      
+      dynamic loading
+      
+       
+        If a dynamically loadable module needs to be opened and the
+        file name specified in the CREATE FUNCTION or
+        LOAD command
+        does not have a directory component (i.e. the
+        name does not contain a slash), the system will search this
+        path for the required file.
+       
+
+       
+        The value for dynamic_library_path has to be a
+        list of absolute directory paths separated by colons (or semi-colons
+        on Windows).  If a list element starts
+        with the special string $libdir, the
+        compiled-in PostgreSQL package
+        library directory is substituted for $libdir. This
+        is where the modules provided by the standard
+        PostgreSQL distribution are installed.
+        (Use pg_config --pkglibdir to find out the name of
+        this directory.) For example:
+
+dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
+
+        or, in a Windows environment:
+
+dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
+
+       
+
+       
+        The default value for this parameter is
+        '$libdir'. If the value is set to an empty
+        string, the automatic path search is turned off.
+       
+
+       
+        This parameter can be changed at run time by superusers, but a
+        setting done that way will only persist until the end of the
+        client connection, so this method should be reserved for
+        development purposes. The recommended way to set this parameter
+        is in the postgresql.conf configuration
+        file.
+       
+      
+     
+
+     
+    
+   
+
+   
+    Lock Management
+
+     
+
+     
+      
+       deadlock
+       timeout during
+      
+      
+       timeout
+       deadlock
+      
+      
+       deadlock_timeout configuration parameter
+      
+
+      deadlock_timeout (integer)
+      
+       
+        This is the amount of time, in milliseconds, to wait on a lock
+        before checking to see if there is a deadlock condition. The
+        check for deadlock is relatively slow, so the server doesn't run
+        it every time it waits for a lock. We (optimistically?) assume
+        that deadlocks are not common in production applications and
+        just wait on the lock for a while before starting the check for a
+        deadlock. Increasing this value reduces the amount of time
+        wasted in needless deadlock checks, but slows down reporting of
+        real deadlock errors. The default is 1000 (i.e., one second),
+        which is probably about the smallest value you would want in
+        practice. On a heavily loaded server you might want to raise it.
+        Ideally the setting should exceed your typical transaction time,
+        so as to improve the odds that a lock will be released before
+        the waiter decides to check for deadlock.
+       
+      
+     
+
+     
+      max_locks_per_transaction (integer)
+      
+       max_locks_per_transaction configuration parameter
+      
+      
+       
+        The shared lock table is created with room to describe locks on
+        max_locks_per_transaction *
+        ( +
+        ) objects;
+        hence, no more than this many distinct objects can
+        be locked at any one time. (Thus, this parameter's name may be
+        confusing: it is not a hard limit on the number of locks taken
+        by any one transaction, but rather a maximum average value.)
+        The default, 64, has historically
+        proven sufficient, but you might need to raise this value if you
+        have clients that touch many different tables in a single
+        transaction. This option can only be set at server start.
+       
+
+       
+        Increasing this parameter may cause PostgreSQL
+        to request more System V shared
+        memory than your operating system's default configuration
+        allows. See  for information on how to
+        adjust those parameters, if necessary.
+       
+      
+     
+
+     
+   
+
+   
+    Version and Platform Compatibility
+
+    
+     Previous PostgreSQL Versions
+     
+
+     
+      add_missing_from (boolean)
+      FROMmissing
+      
+       add_missing_from configuration parameter
+      
+      
+       
+        When on, tables that are referenced by a query will be
+        automatically added to the FROM clause if not
+        already present. This behavior does not comply with the SQL
+        standard and many people dislike it because it can mask mistakes
+        (such as referencing a table where you should have referenced
+        its alias). The default is off. This variable can be
+        enabled for compatibility with releases of
+        PostgreSQL prior to 8.1, where this behavior was
+        allowed by default.
+       
+
+       
+        Note that even when this variable is enabled, a warning
+        message will be emitted for each implicit FROM
+        entry referenced by a query. Users are encouraged to update
+        their applications to not rely on this behavior, by adding all
+        tables referenced by a query to the query's FROM
+        clause (or its USING clause in the case of
+        DELETE).
+       
+      
+     
+
+     
+      regex_flavor (string)
+      regular expressions
+      
+       regex_flavor configuration parameter
+      
+      
+       
+        The regular expression flavor can be set to
+        advanced, extended, or basic.
+        The default is advanced.  The extended
+        setting may be useful for exact backwards compatibility with
+        pre-7.4 releases of PostgreSQL.  See
+         for details.
+       
+      
+     
+
+     
+      sql_inheritance (boolean)
+      
+       sql_inheritance configuration parameter
+      
+      inheritance
+      
+       
+        This controls the inheritance semantics, in particular whether
+        subtables are included by various commands by default. They were
+        not included in versions prior to 7.1. If you need the old
+        behavior you can set this variable to off, but in
+        the long run you are encouraged to change your applications to
+        use the ONLY key word to exclude subtables.
+        See  for more information about
+        inheritance.
+       
+      
+     
+
+     
+      default_with_oids (boolean)
+      
+       default_with_oids configuration parameter
+      
+      
+       
+        This controls whether CREATE TABLE and
+        CREATE TABLE AS include an OID column in
+        newly-created tables, if neither WITH OIDS
+        nor WITHOUT OIDS is specified. It also
+        determines whether OIDs will be included in tables created by
+        SELECT INTO. In PostgreSQL
+        8.1 default_with_oids is disabled by default; in
+        prior versions of PostgreSQL, it was on by default.
+       
+
+       
+        The use of OIDs in user tables is considered deprecated, so
+        most installations should leave this variable disabled.
+        Applications that require OIDs for a particular table should
+        specify WITH OIDS when creating the
+        table. This variable can be enabled for compatibility with old
+        applications that do not follow this behavior.
+       
+      
+     
+
+     
+      escape_string_warning (boolean)
+      stringsescape
+      
+       escape_string_warning configuration parameter
+      
+      
+       
+        When on, a warning is issued if a backslash (\)
+        appears in an ordinary string literal ('...'
+        syntax). The default is off.
+       
+       
+        Escape string syntax (E'...') should be used for
+        escapes, because in future versions of
+        PostgreSQL ordinary strings will have
+        the standard-conforming behavior of treating backslashes
+        literally.
+       
+      
+     
+
+     
+    
+    
+     Platform and Client Compatibility
+     
+
+     
+      transform_null_equals (boolean)
+      IS NULL
+      
+       transform_null_equals configuration parameter
+      
+      
+       
+        When on, expressions of the form expr =
+        NULL (or NULL =
+        expr) are treated as
+        expr IS NULL, that is, they
+        return true if expr evaluates to the null value,
+        and false otherwise. The correct SQL-spec-compliant behavior of
+        expr = NULL is to always
+        return null (unknown). Therefore this option defaults to
+        off.
+       
+
+       
+        However, filtered forms in Microsoft
+        Access generate queries that appear to use
+        expr = NULL to test for
+        null values, so if you use that interface to access the database you
+        might want to turn this option on.  Since expressions of the
+        form expr = NULL always
+        return the null value (using the correct interpretation) they are not
+        very useful and do not appear often in normal applications, so
+        this option does little harm in practice.  But new users are
+        frequently confused about the semantics of expressions
+        involving null values, so this option is not on by default.
+       
+
+       
+        Note that this option only affects the exact form = NULL,
+        not other comparison operators or other expressions
+        that are computationally equivalent to some expression
+        involving the equals operator (such as IN).
+        Thus, this option is not a general fix for bad programming.
+       
+
+       
+        Refer to  for related information.
+       
+      
+     
+
+     
+    
+   
+
+   
+    Preset Options
+
+    
+     The following parameters are read-only, and are determined
+     when PostgreSQL is compiled or when it is
+     installed. As such, they have been excluded from the sample
+     postgresql.conf file.  These options report
+     various aspects of PostgreSQL behavior
+     that may be of interest to certain applications, particularly
+     administrative front-ends.
+    
+
+    
+
+     
+      block_size (integer)
+      
+       block_size configuration parameter
+      
+      
+       
+        Reports the size of a disk block.  It is determined by the value
+        of BLCKSZ when building the server. The default
+        value is 8192 bytes.  The meaning of some configuration
+        variables (such as ) is
+        influenced by block_size. See 
+        linkend="runtime-config-resource"> for information.
+       
+      
+     
+
+     
+      integer_datetimes (boolean)
+      
+       integer_datetimes configuration parameter
+      
+      
+       
+        Reports whether PostgreSQL was built
+        with support for 64-bit-integer dates and times.  It is set by
+        configuring with --enable-integer-datetimes
+        when building PostgreSQL.  The
+        default value is off.
+       
+      
+     
+
+     
+      lc_collate (string)
+      
+       lc_collate configuration parameter
+      
+      
+       
+        Reports the locale in which sorting of textual data is done.
+        See  for more information.
+        The value is determined when the database cluster is initialized.
+       
+      
+     
+
+     
+      lc_ctype (string)
+      
+       lc_ctype configuration parameter
+      
+      
+       
+        Reports the locale that determines character classifications.
+        See  for more information.
+        The value is determined when the database cluster is initialized.
+        Ordinarily this will be the same as lc_collate,
+        but for special applications it might be set differently.
+       
+      
+     
+
+     
+      max_function_args (integer)
+      
+       max_function_args configuration parameter
+      
+      
+       
+        Reports the maximum number of function arguments. It is determined by
+        the value of FUNC_MAX_ARGS when building the server. The
+        default value is 100.
+       
+      
+     
+
+     
+      max_identifier_length (integer)
+      
+       max_identifier_length configuration parameter
+      
+      
+       
+        Reports the maximum identifier length. It is determined as one
+        less than the value of NAMEDATALEN when building
+        the server. The default value of NAMEDATALEN is
+        64; therefore the default
+        max_identifier_length is 63.
+       
+      
+     
+
+     
+      max_index_keys (integer)
+      
+       max_index_keys configuration parameter
+      
+      
+       
+        Reports the maximum number of index keys. It is determined by
+        the value of INDEX_MAX_KEYS when building the server. The
+        default value is 32.
+       
+      
+     
+
+     
+      server_encoding (string)
+      
+       server_encoding configuration parameter
+      
+      character set
+      
+       
+        Reports the database encoding (character set).
+        It is determined when the database is created.  Ordinarily,
+        clients need only be concerned with the value of 
+        linkend="guc-client-encoding">.
+       
+      
+     
+
+     
+      server_version (string)
+      
+       server_version configuration parameter
+      
+      
+       
+        Reports the version number of the server. It is determined by the
+        value of PG_VERSION when building the server.
+       
+      
+     
+
+     
+      standard_conforming_strings (boolean)
+      stringsescape
+      
+       standard_conforming_strings configuration parameter
+      
+      
+       
+        Reports whether ordinary string literals
+        ('...') treat backslashes literally, as specified in
+        the SQL standard.  The value is currently always off,
+        indicating that backslashes are treated as escapes.  It is planned
+        that this will change to on in a future
+        PostgreSQL release when string literal
+        syntax changes to meet the standard.  Applications may check this
+        parameter to determine how string literals will be processed.
+        The presence of this parameter can also be taken as an indication
+        that the escape string syntax (E'...') is supported.
+       
+      
+     
+
+    
+   
+
+   
+    Customized Options
+
+    
+     This feature was designed to allow options not normally known to
+     PostgreSQL to be added by add-on modules
+     (such as procedural languages).  This allows add-on modules to be
+     configured in the standard ways.
+    
+
+    
+
+     
+      custom_variable_classes (string)
+      
+       custom_variable_classes configuration parameter
+      
+      
+       
+        This variable specifies one or several class names to be used for
+        custom variables, in the form of a comma-separated list. A custom
+        variable is a variable not normally known
+        to PostgreSQL proper but used by some
+        add-on module.  Such variables must have names consisting of a class
+        name, a dot, and a variable name.  custom_variable_classes
+        specifies all the class names in use in a particular installation.
+        This option can only be set at server start or in the
+        postgresql.conf configuration file.
+       
+
+      
+     
+    
+
+    
+     The difficulty with setting custom variables in
+     postgresql.conf is that the file must be read before add-on
+     modules have been loaded, and so custom variables would ordinarily be
+     rejected as unknown.  When custom_variable_classes is set,
+     the server will accept definitions of arbitrary variables within each
+     specified class.  These variables will be treated as placeholders and
+     will have no function until the module that defines them is loaded. When a
+     module for a specific class is loaded, it will add the proper variable
+     definitions for its class name, convert any placeholder
+     values according to those definitions, and issue warnings for any
+     placeholders of its class that remain (which presumably would be
+     misspelled configuration variables).
+    
+
+    
+     Here is an example of what postgresql.conf might contain
+     when using custom variables:
+
+
+custom_variable_classes = 'plr,plperl'
+plr.path = '/usr/lib/R'
+plperl.use_strict = true
+plruby.use_strict = true        # generates error: unknown class name
+
+    
+   
+
+   
+    Developer Options
+
+    
+     The following options are intended for work on the
+     PostgreSQL source, and in some cases
+     to assist with recovery of severely damaged databases.  There
+     should be no reason to use them in a production database setup.
+     As such, they have been excluded from the sample
+     postgresql.conf file.  Note that many of these
+     options require special source compilation flags to work at all.
+    
+
+    
+     
+      debug_assertions (boolean)
+      
+       debug_assertions configuration parameter
+      
+      
+       
+        Turns on various assertion checks. This is a debugging aid. If
+        you are experiencing strange problems or crashes you might want
+        to turn this on, as it might expose programming mistakes. To use
+        this option, the macro USE_ASSERT_CHECKING
+        must be defined when PostgreSQL is
+        built (accomplished by the configure option
+        --enable-cassert). Note that
+        debug_assertions defaults to on
+        if PostgreSQL has been built with
+        assertions enabled.
+       
+      
+     
+
+     
+      pre_auth_delay (integer)
+      
+       pre_auth_delay configuration parameter
+      
+      
+       
+        If nonzero, a delay of this many seconds occurs just after a new
+        server process is forked, before it conducts the authentication
+        process.  This is intended to give an opportunity to attach to the
+        server process with a debugger to trace down misbehavior in
+        authentication.
+       
+      
+     
+
+     
+      trace_notify (boolean)
+      
+       trace_notify configuration parameter
+      
+      
+       
+        Generates a great amount of debugging output for the
+        LISTEN and NOTIFY
+        commands.   or
+         must be
+        DEBUG1 or lower to send this output to the
+        client or server log, respectively.
+       
+      
+     
+
+     
+      trace_locks (boolean)
+      trace_lwlocks (boolean)
+      trace_userlocks (boolean)
+      trace_lock_oidmin (boolean)
+      trace_lock_table (boolean)
+      debug_deadlocks (boolean)
+      log_btree_build_stats (boolean)
+      
+       
+        Various other code tracing and debugging options.
+       
+      
+     
+
+     
+      wal_debug (boolean)
+      
+       wal_debug configuration parameter
+      
+      
+       
+        If on, emit WAL-related debugging output. This option is
+        only available if the WAL_DEBUG macro was
+        defined when PostgreSQL was
+        compiled.
+       
+      
+     
+
+    
+      zero_damaged_pages (boolean)
+      
+       zero_damaged_pages configuration parameter
+      
+      
+       
+        Detection of a damaged page header normally causes
+        PostgreSQL to report an error, aborting the current
+        command.  Setting zero_damaged_pages to on causes
+        the system to instead report a warning, zero out the damaged page,
+        and continue processing.  This behavior will destroy data,
+        namely all the rows on the damaged page.  But it allows you to get
+        past the error and retrieve rows from any undamaged pages that may
+        be present in the table.  So it is useful for recovering data if
+        corruption has occurred due to hardware or software error.  You should
+        generally not set this on until you have given up hope of recovering
+        data from the damaged page(s) of a table.  The
+        default setting is off, and it can only be changed
+        by a superuser.
+       
+      
+     
+   
+  
+  
+   Short Options
+
+   
+    For convenience there are also single letter command-line option switches
+    available for some parameters. They are described in 
+    linkend="runtime-config-short-table">.
+   
+
+    
+     Short option key
+     
+      
+       
+        Short option
+        Equivalent
+       
+      
+
+      
+       
+        -B x
+        shared_buffers = x
+       
+       
+        -d x
+        log_min_messages = DEBUGx
+       
+       
+        -F
+        fsync = off
+       
+       
+        -h x
+        listen_addresses = x
+       
+       
+        -i
+        listen_addresses = '*'
+       
+       
+        -k x
+        unix_socket_directory = x
+       
+       
+        -l
+        ssl = on
+       
+       
+        -N x
+        max_connections = x
+       
+       
+        -p x
+        port = x
+       
+
+       
+        
+          -fb, -fh, -fi,
+          -fm, -fn,
+          -fs, -ft
+          id="fn.runtime-config-short">
+           
+            For historical reasons, these options must be passed to
+            the individual server process via the -o
+            postmaster option, for example,
+
+$ postmaster -o '-S 1024 -s'
+
+            or via PGOPTIONS from the client side, as
+            explained above.
+           
+          
+         
+         
+          enable_bitmapscan = off,
+          enable_hashjoin = off,
+          enable_indexscan = off,
+          enable_mergejoin = off,
+          enable_nestloop = off,
+          enable_seqscan = off,
+          enable_tidscan = off
+         
+       
+
+       
+        -s
+        log_statement_stats = on
+       
+
+       
+        -S x
+        
+        work_mem = x
+       
+
+       
+        -tpa, -tpl, -te
+        log_parser_stats = on,
+        log_planner_stats = on, 
+        log_executor_stats = on
+       
+      
+     
+    
+
+  
+
+
+


diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml

index 88487ee93887f2b7c4afd7b729ffa213aa3d9117..3b1cd740057bbd19f3c90d8bee384f9f0ab143cb 100644 (file)

--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -1,4 +1,4 @@
-
+
 
 
 
@@ -41,6 +41,7 @@
 
 
 
+
 
 
 


diff --git a/doc/src/sgml/postgres.sgml b/doc/src/sgml/postgres.sgml

index 6fa0e28191b79d99b68921f4ed46475c40fba758..8099f72dd8bb578cf640505080c99d70cd2da914 100644 (file)

--- a/doc/src/sgml/postgres.sgml
+++ b/doc/src/sgml/postgres.sgml
@@ -1,5 +1,5 @@
 
 
 
@@ -146,6 +146,7 @@ $PostgreSQL: pgsql/doc/src/sgml/postgres.sgml,v 1.75 2005/02/27 00:49:28 momjian
   &installation;
   &installw;
   &runtime;
+  &config;
   &user-manag;
   &manage-ag;
   &client-auth;


diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml

index 5af562a6635fecf531be01e97b6be7582e939c9c..3a8745df90955e6ce0736cb85ca6e989e0a84a88 100644 (file)

--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -1,5 +1,5 @@
 
 
 
@@ -451,4224 +451,6 @@ psql: could not connect to server: No such file or directory
    
   
 
-  
-   Run-time Configuration
-
-   
-    configuration
-    of the server
-   
-
-   
-    There are a lot of configuration parameters that affect the
-    behavior of the database system. In this subsection, we describe
-    how to set configuration parameters; the following subsections
-    discuss each parameter in detail.
-   
-
-   
-    All parameter names are case-insensitive. Every parameter takes a
-    value of one of four types: boolean, integer, floating point,
-    or string. Boolean values may be written as ON,
-    OFF, TRUE,
-    FALSE, YES,
-    NO, 1, 0
-    (all case-insensitive) or any unambiguous prefix of these.
-   
-
-   
-    One way to set these parameters is to edit the file
-    postgresql.confpostgresql.conf,
-    which is normally kept in the data directory. (initdb
-    installs a default copy there.) An example of what this file might look
-    like is:
-
-# This is a comment
-log_connections = yes
-log_destination = 'syslog'
-search_path = '$user, public'
-
-    One parameter is specified per line. The equal sign between name and
-    value is optional. Whitespace is insignificant and blank lines are
-    ignored. Hash marks (#) introduce comments
-    anywhere.  Parameter values that are not simple identifiers or
-    numbers must be single-quoted.
-   
-
-   
-    
-     SIGHUP
-    
-    The configuration file is reread whenever the
-    postmaster process receives a
-    SIGHUP signal (which is most easily sent by means
-    of pg_ctl reload). The postmaster
-    also propagates this signal to all currently running server
-    processes so that existing sessions also get the new
-    value. Alternatively, you can send the signal to a single server
-    process directly.  Some parameters can only be set at server start;
-    any changes to their entries in the configuration file will be ignored
-    until the server is restarted.
-   
-
-   
-    A second way to set these configuration parameters is to give them
-    as a command line option to the postmaster, such as:
-
-postmaster -c log_connections=yes -c log_destination='syslog'
-
-    Command-line options override any conflicting settings in
-    postgresql.conf.  Note that this means you won't
-    be able to change the value on-the-fly by editing
-    postgresql.conf, so while the command-line
-    method may be convenient, it can cost you flexibility later.
-   
-
-   
-    Occasionally it is useful to give a command line option to
-    one particular session only. The environment variable
-    PGOPTIONS can be used for this purpose on the
-    client side:
-
-env PGOPTIONS='-c geqo=off' psql
-
-    (This works for any libpq-based client application, not
-    just psql.) Note that this won't work for
-    parameters that are fixed when the server is started or that must be
-    specified in postgresql.conf.
-   
-
-   
-    Furthermore, it is possible to assign a set of option settings to
-    a user or a database.  Whenever a session is started, the default
-    settings for the user and database involved are loaded.  The
-    commands 
-    and ,
-    respectively, are used to configure these settings.  Per-database
-    settings override anything received from the
-    postmaster command-line or the configuration
-    file, and in turn are overridden by per-user settings; both are
-    overridden by per-session options.
-   
-
-   
-    Some parameters can be changed in individual SQL
-    sessions with the 
-    command, for example:
-
-SET ENABLE_SEQSCAN TO OFF;
-
-    If SET is allowed, it overrides all other sources of
-    values for the parameter. Some parameters cannot be changed via
-    SET: for example, if they control behavior that
-    cannot reasonably be changed without restarting
-    PostgreSQL.  Also, some parameters can
-    be modified via SET or ALTER by superusers,
-    but not by ordinary users.
-   
-
-   
-    The 
-    command allows inspection of the current values of all parameters.
-   
-
-   
-    The virtual table pg_settings
-    (described in ) also allows
-    displaying and updating session run-time parameters.  It is equivalent
-    to SHOW and SET, but can be more convenient
-    to use because it can be joined with other tables, or selected from using
-    any desired selection condition.
-   
-    
-   
-    File Locations
-
-     
-      In addition to the postgresql.conf file
-      already mentioned, PostgreSQL uses
-      two other manually-edited configuration files, which control
-      client authentication (their use is discussed in 
-      linkend="client-authentication">).
-      By default, all three configuration files are stored
-      in the database cluster's data directory.  The options described
-      in this subsection allow the configuration files to be placed elsewhere.
-      (Doing so can ease administration.  In particular it is often
-      easier to ensure that the configuration files are properly backed-up
-      when they are kept separate.)
-     
-
-     
-     
-      data_directory (string)
-      
-       data_directory configuration parameter
-      
-      
-       
-         Specifies the directory to use for data storage.
-         This option can only be set at server start.
-       
-      
-     
-
-     
-      config_file (string)
-      
-       config_file configuration parameter
-      
-      
-       
-         Specifies the main server configuration file
-         (customarily called postgresql.conf).
-         This option can only be set on the postmaster command line.
-       
-      
-     
-
-     
-      hba_file (string)
-      
-       hba_file configuration parameter
-      
-      
-       
-         Specifies the configuration file for host-based authentication
-         (customarily called pg_hba.conf).
-         This option can only be set at server start.
-       
-      
-     
-
-     
-      ident_file (string)
-      
-       ident_file configuration parameter
-      
-      
-       
-         Specifies the configuration file for
-         ident authentication
-         (customarily called pg_ident.conf).
-         This option can only be set at server start.
-       
-      
-     
-
-     
-      external_pid_file (string)
-      
-       external_pid_file configuration parameter
-      
-      
-       
-        Specifies the name of an additional process-id (PID) file that the
-        postmaster should create for use by server
-        administration programs.
-        This option can only be set at server start.
-       
-      
-     
-     
-
-     
-      In a default installation, none of the above options are set explicitly.
-      Instead, the
-      data directory is specified by the -D command-line
-      option or the PGDATA environment variable, and the
-      configuration files are all found within the data directory.
-     
-
-     
-      If you wish to keep the configuration files elsewhere than the
-      data directory, the postmaster's -D
-      command-line option or PGDATA environment variable
-      must point to the directory containing the configuration files,
-      and the data_directory option must be set in
-      postgresql.conf (or on the command line) to show
-      where the data directory is actually located.  Notice that
-      data_directory overrides -D and
-      PGDATA for the location
-      of the data directory, but not for the location of the configuration
-      files.
-     
-
-     
-      If you wish, you can specify the configuration file names and locations
-      individually using the options config_file,
-      hba_file and/or ident_file.
-      config_file can only be specified on the 
-      postmaster command line, but the others can be
-      set within the main configuration file.  If all three options plus
-      data_directory are explicitly set, then it is not necessary
-      to specify -D or PGDATA.
-     
-
-     
-      When setting any of these options, a relative path will be interpreted
-      with respect to the directory in which the postmaster
-      is started.
-     
-   
-
-   
-    Connections and Authentication
-
-    
-     Connection Settings
-
-     
-
-     
-      listen_addresses (string)
-      
-       listen_addresses configuration parameter
-      
-      
-       
-         Specifies the TCP/IP address(es) on which the server is
-         to listen for connections from client applications.  
-         The value takes the form of a comma-separated list of host names
-         and/or numeric IP addresses.  The special entry *
-         corresponds to all available IP interfaces.
-         If the list is empty, the server does not listen on any IP interface
-         at all, in which case only Unix-domain sockets can be used to connect
-         to it.
-         The default value is localhost,
-         which allows only local loopback connections to be made.
-         This parameter can only be set at server start.
-       
-      
-     
-
-     
-      port (integer)
-      
-       port configuration parameter
-      
-      
-       
-        The TCP port the server listens on; 5432 by default.  Note that the
-        same port number is used for all IP addresses the server listens on.
-        This parameter can only be set at server start.
-       
-      
-     
-
-     
-      max_connections (integer)
-      
-       max_connections configuration parameter
-      
-      
-       
-        Determines the maximum number of concurrent connections to the
-        database server. The default is typically 100, but may be less
-        if your kernel settings will not support it (as determined
-        during initdb).  This parameter can only be
-        set at server start.
-       
-
-       
-        Increasing this parameter may cause PostgreSQL
-        to request more System V shared
-        memory or semaphores than your operating system's default configuration
-        allows. See  for information on how to
-        adjust those parameters, if necessary.
-       
-      
-     
-     
-     
-     xreflabel="superuser_reserved_connections">
-      superuser_reserved_connections
-      (integer)
-      
-       superuser_reserved_connections configuration parameter
-      
-      
-       
-        Determines the number of connection slots that
-        are reserved for connections by PostgreSQL
-        superusers.  At most 
-        connections can ever be active simultaneously.  Whenever the
-        number of active concurrent connections is at least
-        max_connections minus
-        superuser_reserved_connections, new
-        connections will be accepted only for superusers.
-       
-
-       
-        The default value is 2. The value must be less than the value of
-        max_connections. This parameter can only be
-        set at server start.
-       
-      
-     
-
-     
-      unix_socket_directory (string)
-      
-       unix_socket_directory configuration parameter
-      
-      
-       
-        Specifies the directory of the Unix-domain socket on which the
-        server is to listen for
-        connections from client applications.  The default is normally
-        /tmp, but can be changed at build time.
-        This parameter can only be set at server start.
-       
-      
-     
-
-     
-      unix_socket_group (string)
-      
-       unix_socket_group configuration parameter
-      
-      
-       
-        Sets the owning group of the Unix-domain socket.  (The owning
-        user of the socket is always the user that starts the
-        server.)  In combination with the option
-        unix_socket_permissions this can be used as
-        an additional access control mechanism for Unix-domain connections.
-        By default this is the empty string, which uses the default
-        group for the current user.  This option can only be set at
-        server start.
-       
-      
-     
-
-     
-      unix_socket_permissions (integer)
-      
-       unix_socket_permissions configuration parameter
-      
-      
-       
-        Sets the access permissions of the Unix-domain socket.  Unix-domain
-        sockets use the usual Unix file system permission set.
-        The option value is expected to be a numeric mode
-        specification in the form accepted by the
-        chmod and umask
-        system calls.  (To use the customary octal format the number
-        must start with a 0 (zero).)
-       
-
-       
-        The default permissions are 0777, meaning
-        anyone can connect. Reasonable alternatives are
-        0770 (only user and group, see also
-        unix_socket_group) and 0700
-        (only user). (Note that for a Unix-domain socket, only write
-        permission matters and so there is no point in setting or revoking
-        read or execute permissions.)
-       
-
-       
-        This access control mechanism is independent of the one
-        described in .
-       
-
-       
-        This option can only be set at server start.
-       
-      
-     
-     
-     
-      bonjour_name (string)
-      
-       bonjour_name configuration parameter
-      
-      
-       
-        Specifies the Bonjour broadcast
-        name.  By default, the computer name is used, specified as an
-        empty string ''.  This option is ignored if the server was not
-        compiled with Bonjour support.  This
-        option can only be set at server start.
-       
-      
-     
-     
-     
-      tcp_keepalives_idle (integer)
-      
-       tcp_keepalives_idle configuration parameter
-      
-      
-       
-        On systems that support the TCP_KEEPIDLE socket option, specifies the
-        number of seconds between sending keepalives on an otherwise idle
-        connection. A value of 0 uses the system default. If TCP_KEEPIDLE is
-        not supported, this parameter must be 0. This option is ignored for
-        connections made via a Unix-domain socket.
-       
-      
-     
-     
-     
-      tcp_keepalives_interval (integer)
-      
-       tcp_keepalives_interval configuration parameter
-      
-      
-       
-        On systems that support the TCP_KEEPINTVL socket option, specifies how
-        long, in seconds, to wait for a response to a keepalive before
-        retransmitting. A value of 0 uses the system default. If TCP_KEEPINTVL
-        is not supported, this parameter must be 0. This option is ignored
-        for connections made via a Unix-domain socket.
-       
-      
-     
-     
-     
-      tcp_keepalives_count (integer)
-      
-       tcp_keepalives_count configuration parameter
-      
-      
-       
-        On systems that support the TCP_KEEPCNT socket option, specifies how
-        many keepalives may be lost before the connection is considered dead. 
-        A value of 0 uses the system default. If TCP_KEEPINTVL is not
-        supported, this parameter must be 0.
-       
-      
-     
-     
-     
-     
-     
-     Security and Authentication
-     
-     
-     
-      authentication_timeout (integer)
-      timeoutclient authentication
-      client authenticationtimeout during
-      
-       authentication_timeout configuration parameter
-      
-
-      
-       
-        Maximum time to complete client authentication, in seconds. If a
-        would-be client has not completed the authentication protocol in
-        this much time, the server breaks the connection. This prevents
-        hung clients from occupying a connection indefinitely. This
-        option can only be set at server start or in the
-        postgresql.conf file. The default is 60.
-       
-      
-     
-     
-     
-      ssl (boolean)
-      
-       ssl configuration parameter
-      
-      
-       
-        Enables SSL connections. Please read
-         before using this. The default
-        is off. This parameter can only be set at server
-        start.
-       
-      
-     
-
-     
-      password_encryption (boolean)
-      
-       password_encryption configuration parameter
-      
-      
-       
-        When a password is specified in 
-        linkend="sql-createuser" endterm="sql-createuser-title"> or
-        
-        without writing either ENCRYPTED or
-        UNENCRYPTED, this option determines whether the
-        password is to be encrypted. The default is on
-        (encrypt the password).
-       
-      
-     
-
-     
-      krb_server_keyfile (string)
-      
-       krb_server_keyfile configuration parameter
-      
-      
-       
-        Sets the location of the Kerberos server key file. See
-         for details. This parameter
-        can only be set at server start.
-       
-      
-     
-
-     
-      krb_srvname (string)
-      
-       krb_srvname configuration parameter
-      
-      
-       
-        Sets the Kerberos service name. See 
-        for details.  This parameter can only be set at server start.
-       
-      
-     
-
-     
-      krb_server_hostname (string)
-      
-       krb_server_hostname configuration parameter
-      
-      
-       
-        Sets the hostname part of the service principal.
-        This, combined with krb_srvname, is used to generate
-        the complete service principal, i.e.
-        krb_server_hostname/krb_server_hostname@REALM.
-       
-       
-        If not set, the default is to allow any service principal matching an entry
-        in the keytab.  See  for details.
-        This parameter can only be set at server start.
-       
-      
-     
-
-     
-      krb_caseins_users (boolean)
-      
-       krb_caseins_users configuration parameter
-      
-      
-       
-        Sets if Kerberos usernames should be treated case-insensitively.
-        The default is off (case sensitive). This parameter
-        can only be set at server start.
-       
-      
-     
-
-     
-      db_user_namespace (boolean)
-      
-       db_user_namespace configuration parameter
-      
-      
-       
-        This enables per-database user names.  It is off by default.
-       
-
-       
-        If this is on, you should create users as username@dbname.
-        When username is passed by a connecting client,
-        @ and the database name are appended to the user
-        name and that database-specific user name is looked up by the
-        server. Note that when you create users with names containing
-        @ within the SQL environment, you will need to
-        quote the user name.
-       
-
-       
-        With this option enabled, you can still create ordinary global
-        users.  Simply append @ when specifying the user
-        name in the client.  The @ will be stripped off
-        before the user name is looked up by the server.
-       
-
-       
-        
-         This feature is intended as a temporary measure until a
-         complete solution is found.  At that time, this option will
-         be removed.
-        
-       
-      
-     
-
-    
-    
-   
-
-   
-    Resource Consumption
-
-    
-     Memory
-
-     
-     
-      shared_buffers (integer)
-      
-       shared_buffers configuration parameter
-      
-      
-       
-        Sets the number of shared memory buffers used by the database
-        server. The default is typically 1000, but may be less if your
-        kernel settings will not support it (as determined during
-        initdb).  Each buffer is 8192 bytes, unless a
-        different value of BLCKSZ was chosen when building
-        the server.  This setting must be at least 16, as well as at
-        least twice the value of ;
-        however, settings significantly higher than the minimum are
-        usually needed for good performance.  Values of a few thousand
-        are recommended for production installations.  This option can
-        only be set at server start.
-       
-
-       
-        Increasing this parameter may cause PostgreSQL
-        to request more System V shared
-        memory than your operating system's default configuration
-        allows. See  for information on how to
-        adjust those parameters, if necessary.
-       
-      
-     
-
-     
-      temp_buffers (integer)
-      
-       temp_buffers configuration parameter
-      
-      
-       
-        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 1000.  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.
-       
-
-       
-        A session will allocate temporary buffers as needed up to the limit
-        given by temp_buffers.  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 temp_buffers.  However if a buffer is
-        actually used an additional 8192 bytes will be consumed for it
-        (or in general, BLCKSZ bytes).
-       
-      
-     
-
-     
-      max_prepared_transactions (integer)
-      
-       max_prepared_transactions configuration parameter
-      
-      
-       
-        Sets the maximum number of transactions that can be in the
-        prepared state simultaneously (see 
-        linkend="sql-prepare-transaction"
-        endterm="sql-prepare-transaction-title">).
-        Setting this parameter to zero disables the prepared-transaction
-        feature.
-        The default is 5.
-        This option can only be set at server start.
-       
-
-       
-        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 max_prepared_transactions to be at least
-        as large as , to avoid unwanted
-        failures at the prepare step.
-       
-
-       
-        Increasing this parameter may cause PostgreSQL
-        to request more System V shared
-        memory than your operating system's default configuration
-        allows. See  for information on how to
-        adjust those parameters, if necessary.
-       
-      
-     
-
-     
-      work_mem (integer)
-      
-       work_mem configuration parameter
-      
-      
-       
-        Specifies the amount of memory to be used by internal sort operations
-        and hash tables before switching to temporary disk files. The value is
-        specified in kilobytes, and defaults to 1024 kilobytes (1 MB).
-        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 work_mem; it is necessary to
-        keep this fact in mind when choosing the value. Sort operations are
-        used for ORDER BY, DISTINCT, and
-        merge joins.
-        Hash tables are used in hash joins, hash-based aggregation, and
-        hash-based processing of IN subqueries.
-       
-      
-     
-     
-     
-      maintenance_work_mem (integer)
-      
-       maintenance_work_mem configuration parameter
-      
-      
-       
-        Specifies the maximum amount of memory to be used in maintenance
-        operations, such as VACUUM, CREATE
-        INDEX, and ALTER TABLE ADD FOREIGN KEY.
-        The value is specified in kilobytes, and defaults to 16384 kilobytes
-        (16 MB).  Since only one of these operations can be executed at 
-        a time by a database session, and an installation normally doesn't
-        have very many of them happening concurrently, it's safe to set this
-        value significantly larger than work_mem.  Larger
-        settings may improve performance for vacuuming and for restoring
-        database dumps.
-       
-      
-     
-
-     
-      max_stack_depth (integer)
-      
-       max_stack_depth configuration parameter
-      
-      
-       
-        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 ulimit -s 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.  Setting the parameter higher than
-        the actual kernel limit will mean that a runaway recursive function
-        can crash an individual backend process.  The default setting is
-        2048 KB (two megabytes), which is conservatively small and unlikely
-        to risk crashes.  However, it may be too small to allow execution
-        of complex functions.
-       
-      
-     
-
-     
-     
-     
-     Free Space Map
-
-     
-      free space map
-     
-
-     
-      These parameters control the size of the shared free space
-      map, 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 PostgreSQL
-      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 VACUUM VERBOSE 
-      command can help in determining if the current settings are adequate.
-      A NOTICE message is also printed during such an operation
-      if the current settings are too low.
-     
-
-     
-      Increasing these parameters may cause PostgreSQL
-      to request more System V shared
-      memory than your operating system's default configuration
-      allows. See  for information on how to
-      adjust those parameters, if necessary.
-     
-
-     
-     
-      max_fsm_pages (integer)
-      
-       max_fsm_pages configuration parameter
-      
-      
-       
-        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 more than
-        16 * max_fsm_relations.  The default is 20000.
-        This option can only be set at server start.
-       
-      
-     
-
-     
-      max_fsm_relations (integer)
-      
-       max_fsm_relations configuration parameter
-      
-      
-       
-        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 1000.
-        This option can only be set at server start.
-       
-      
-     
-     
-     
-     
-     
-     Kernel Resource Usage
-     
-
-     
-      max_files_per_process (integer)
-      
-       max_files_per_process configuration parameter
-      
-      
-       
-        Sets the maximum number of simultaneously open files allowed to each
-        server subprocess. The default is 1000. 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 Too many open
-        files failures, try reducing this setting.
-        This option can only be set at server start.
-       
-      
-     
-     
-     
-      preload_libraries (string)
-      
-       preload_libraries configuration parameter
-      
-      
-       
-        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
-        '$libdir/mylib:mylib_init' would cause
-        mylib to be preloaded and mylib_init
-        to be executed. If more than one library is to be loaded,
-        separate their names with commas.
-       
-
-       
-        If a specified library or initialization function is not found,
-        the server will fail to start.
-       
-
-       
-        PostgreSQL procedural language
-        libraries may be preloaded in this way, typically by using the
-        syntax '$libdir/plXXX:plXXX_init' where
-        XXX is pgsql, perl,
-        tcl, or python.
-       
-
-       
-        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.
-       
-      
-     
-
-     
-    
-
-    
-     
-       Cost-Based Vacuum Delay
-     
-
-     
-      During the execution of 
-      endterm="sql-vacuum-title"> and 
-      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
-      vacuum_cost_limit), the process performing
-      the operation will sleep for a while (specified by
-      vacuum_cost_delay). Then it will reset the
-      counter and continue execution.
-     
-
-     
-      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
-      VACUUM and ANALYZE 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.
-     
-
-     
-      This feature is disabled by default. To enable it, set the
-      vacuum_cost_delay variable to a nonzero
-      value.
-     
-
-     
-      
-       vacuum_cost_delay (integer)
-       
-        vacuum_cost_delay configuration parameter
-       
-       
-        
-         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
-         vacuum_cost_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.
-        
-       
-      
-
-      
-       vacuum_cost_page_hit (integer)
-       
-        vacuum_cost_page_hit configuration parameter
-       
-       
-        
-         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.
-        
-       
-      
-
-      
-       vacuum_cost_page_miss (integer)
-       
-        vacuum_cost_page_miss configuration parameter
-       
-       
-        
-         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.
-        
-       
-      
-
-      
-       vacuum_cost_page_dirty (integer)
-       
-        vacuum_cost_page_dirty configuration parameter
-       
-       
-        
-         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.
-        
-       
-      
-
-      
-       vacuum_cost_limit (integer)
-       
-        vacuum_cost_limit configuration parameter
-       
-       
-        
-         The accumulated cost that will cause the vacuuming process to sleep.
-         The default value is 200.
-        
-       
-      
-     
-
-     
-      
-       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 vacuum_cost_delay *
-       accumulated_balance /
-       vacuum_cost_limit with a maximum of
-       vacuum_cost_delay * 4.
-      
-     
-
-    
-
-    
-     Background Writer
-
-     
-      Beginning in PostgreSQL 8.0, there is a separate server
-      process called the background writer, whose sole function
-      is to issue writes of 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 section can be used to tune
-      the behavior for local needs.
-     
-
-     
-      
-       bgwriter_delay (integer)
-       
-        bgwriter_delay configuration parameter
-       
-       
-        
-         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 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 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 only be set at server start or in the
-         postgresql.conf file.
-        
-       
-      
-
-      
-       bgwriter_lru_percent (floating point)
-       
-        bgwriter_lru_percent configuration parameter
-       
-       
-        
-         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
-         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 only be set at server start or in the
-         postgresql.conf file.
-        
-       
-      
-
-      
-       bgwriter_lru_maxpages (integer)
-       
-        bgwriter_lru_maxpages configuration parameter
-       
-       
-        
-         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 only be set at server start or in the
-         postgresql.conf file.
-        
-       
-      
-
-      
-       bgwriter_all_percent (floating point)
-       
-        bgwriter_all_percent configuration parameter
-       
-       
-        
-         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
-         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 bgwriter_delay
-         setting, this will allow the entire shared buffer pool to be scanned
-         about once per minute.
-         This option can only be set at server start or in the
-         postgresql.conf file.
-        
-       
-      
-
-      
-       bgwriter_all_maxpages (integer)
-       
-        bgwriter_all_maxpages configuration parameter
-       
-       
-        
-         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 only be set at server start or in the
-         postgresql.conf file.
-        
-       
-      
-     
-
-     
-      Smaller values of bgwriter_all_percent and
-      bgwriter_all_maxpages 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 bgwriter_lru_percent and
-      bgwriter_lru_maxpages 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 maxpages values and/or both
-      percent values to zero.
-     
-    
-
-   
-
-   
-    Write Ahead Log
-
-   
-    See also  for details on WAL
-    tuning.
-   
-
-    
-     Settings
-     
-     
-     
-      
-       fsync configuration parameter
-      
-      fsync (boolean)
-      
-       
-        If this option is on, the PostgreSQL server
-        will use the fsync() system call in several places
-        to make sure that updates are physically written to disk. This
-        insures that a database cluster will recover to a
-        consistent state after an operating system or hardware crash.
-       
-
-       
-        However, using fsync() results in a
-        performance penalty: when a transaction is committed,
-        PostgreSQL must wait for the
-        operating system to flush the write-ahead log to disk.  When
-        fsync is disabled, the operating system is
-        allowed to do its best in buffering, ordering, and delaying
-        writes. This can result in significantly improved performance.
-        However, if the system crashes, the results of the last few
-        committed transactions may be lost in part or whole. In the
-        worst case, unrecoverable data corruption may occur.
-        (Crashes of the database server itself are not
-        a risk factor here.  Only an operating-system-level crash
-        creates a risk of corruption.)
-       
-
-       
-        Due to the risks involved, there is no universally correct
-        setting for fsync. Some administrators
-        always disable fsync, while others only
-        turn it off for bulk loads, where there is a clear restart
-        point if something goes wrong, whereas some administrators
-        always leave fsync enabled. The default is
-        to enable fsync, for maximum reliability.
-        If you trust your operating system, your hardware, and your
-        utility company (or your battery backup), you can consider
-        disabling fsync.
-       
-
-       
-        This option can only be set at server start or in the
-        postgresql.conf file.  If this option
-        is off, consider also turning off 
-        guc-full-page-writes.
-       
-      
-     
-     
-     
-      wal_sync_method (string)
-      
-       wal_sync_method configuration parameter
-      
-      
-       
-        Method used for forcing WAL updates out to disk.  Possible
-        values are:
-       
-       
-        
-        
-         open_datasync (write WAL files with open() option O_DSYNC)
-        
-        
-        
-        
-         fdatasync (call fdatasync() at each commit),
-        
-        
-        
-        
-         fsync (call fsync() at each commit)
-        
-        
-        
-        
-         fsync_writethrough (force write-through of any disk write cache)
-        
-        
-        
-        
-         open_sync (write WAL files with open() option O_SYNC)
-        
-        
-       
-       
-        Not all of these choices are available on all platforms.
-        The top-most supported option is used as the default.
-        If fsync is off then this setting is irrelevant.
-        This option can only be set at server start or in the
-        postgresql.conf file.
-       
-      
-     
-     
-     
-      
-       full_page_writes configuration parameter
-      
-      full_page_writes (boolean)
-      
-       
-        A page write in process during an operating system crash might
-        be only partially written to disk, leading to an on-disk page
-        that contains a mix of old and new data. During recovery, the
-        row changes stored in WAL are not enough to completely restore
-        the page.
-       
-
-       
-        When this option is on, the PostgreSQL server
-        writes full pages to WAL when they are first modified after a
-        checkpoint so full recovery is possible. Turning this option off
-        might lead to a corrupt system after an operating system crash
-        or power failure because uncorrected partial pages might contain
-        inconsistent or corrupt data. The risks are less but similar to
-        fsync.
-       
-
-       
-        This option can only be set at server start or in the
-        postgresql.conf file.  The default is
-        on.
-       
-      
-     
-     
-     
-      wal_buffers (integer)
-      
-       wal_buffers configuration parameter
-      
-      
-       
-        Number of disk-page buffers allocated in shared memory for WAL data.
-        The default is 8.  The setting need only be large enough to hold
-        the amount of WAL data generated by one typical transaction, since
-        the data is flushed to disk at every transaction commit.
-        This option can only be set at server start.
-       
-
-       
-        Increasing this parameter may cause PostgreSQL
-        to request more System V shared
-        memory than your operating system's default configuration
-        allows. See  for information on how to
-        adjust those parameters, if necessary.
-       
-      
-     
-                
-     
-      commit_delay (integer)
-      
-       commit_delay configuration parameter
-      
-      
-       
-        Time delay between writing a commit record to the WAL buffer
-        and flushing the buffer out to disk, in microseconds. A
-        nonzero delay can allow multiple transactions to be committed
-        with only one fsync() system call, if
-        system load is high enough that additional transactions become
-        ready to commit within the given interval. But the delay is
-        just wasted if no other transactions become ready to
-        commit. Therefore, the delay is only performed if at least
-        commit_siblings other transactions are
-        active at the instant that a server process has written its
-        commit record. The default is zero (no delay).
-       
-      
-     
-
-     
-      commit_siblings (integer)
-      
-       commit_siblings configuration parameter
-      
-      
-       
-        Minimum number of concurrent open transactions to require
-        before performing the commit_delay delay. A larger
-        value makes it more probable that at least one other
-        transaction will become ready to commit during the delay
-        interval. The default is five.
-       
-      
-     
-
-     
-     
-     
-     Checkpoints
-
-    
-     
-      checkpoint_segments (integer)
-      
-       checkpoint_segments configuration parameter
-      
-      
-       
-        Maximum distance between automatic WAL checkpoints, in log
-        file segments (each segment is normally 16 megabytes). The
-        default is three.  This option can only be set at server start
-        or in the postgresql.conf file.
-       
-      
-     
-
-     
-      checkpoint_timeout (integer)
-      
-       checkpoint_timeout configuration parameter
-      
-      
-       
-        Maximum time between automatic WAL checkpoints, in
-        seconds. The default is 300 seconds.  This option can only be
-        set at server start or in the postgresql.conf
-        file.
-       
-      
-     
-
-     
-      checkpoint_warning (integer)
-      
-       checkpoint_warning configuration parameter
-      
-      
-       
-        Write a message to the server log if checkpoints caused by
-        the filling of checkpoint segment files happen closer together
-        than this many seconds.  The default is 30 seconds.
-        Zero turns off the warning.
-       
-      
-     
-
-     
-     
-     
-     Archiving
-
-    
-     
-      archive_command (string)
-      
-       archive_command configuration parameter
-      
-      
-       
-        The shell command to execute to archive a completed segment of
-        the WAL file series. If this is an empty string (the default),
-        WAL archiving is disabled. Any %p in the string is
-        replaced by the absolute path of the file to archive, and any
-        %f is replaced by the file name only. Use
-        %% to embed an actual % character in the
-        command. For more information see 
-        linkend="backup-archiving-wal">. This option can only be set at
-        server start or in the postgresql.conf
-        file.
-       
-       
-        It is important for the command to return a zero exit status if
-        and only if it succeeds.  Examples:
-
-archive_command = 'cp "%p" /mnt/server/archivedir/"%f"'
-archive_command = 'copy "%p" /mnt/server/archivedir/"%f"'  # Windows
-
-       
-      
-     
-     
-     
-    
-   
-
-   
-    Query Planning
-
-    
-     Planner Method Configuration
-
-      
-       These configuration parameters provide a crude method of
-       influencing the query plans chosen by the query optimizer. If
-       the default plan chosen by the optimizer for a particular query
-       is not optimal, a temporary solution may be found by using one
-       of these configuration parameters to force the optimizer to
-       choose a different plan.  Turning one of these settings off
-       permanently is seldom a good idea, however.
-       Better ways to improve the quality of the
-       plans chosen by the optimizer include adjusting the 
-       linkend="runtime-config-query-constants"
-       endterm="runtime-config-query-constants-title">, running 
-       linkend="sql-analyze" endterm="sql-analyze-title"> more
-       frequently, increasing the value of the 
-       linkend="guc-default-statistics-target"> configuration parameter,
-       and increasing the amount of statistics collected for
-       specific columns using ALTER TABLE SET
-       STATISTICS.
-      
-
-     
-     
-      enable_bitmapscan (boolean)
-      
-       bitmap scan
-      
-      
-       enable_bitmapscan configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of bitmap-scan plan
-        types. The default is on.
-       
-      
-     
-
-     
-      enable_hashagg (boolean)
-      
-       enable_hashagg configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of hashed
-        aggregation plan types. The default is on.
-       
-      
-     
-
-     
-      enable_hashjoin (boolean)
-      
-       enable_hashjoin configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of hash-join plan
-        types. The default is on.
-       
-      
-     
-
-     
-      enable_indexscan (boolean)
-      
-       index scan
-      
-      
-       enable_indexscan configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of index-scan plan
-        types. The default is on.
-       
-      
-     
-
-     
-      enable_mergejoin (boolean)
-      
-       enable_mergejoin configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of merge-join plan
-        types. The default is on.
-       
-      
-     
-
-     
-      enable_nestloop (boolean)
-      
-       enable_nestloop configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of nested-loop join
-        plans. It's not possible to suppress nested-loop joins entirely,
-        but turning this variable off discourages the planner from using
-        one if there are other methods available. The default is
-        on.
-       
-      
-     
-
-     
-      enable_seqscan (boolean)
-      
-       sequential scan
-      
-      
-       enable_seqscan configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of sequential scan
-        plan types. It's not possible to suppress sequential scans
-        entirely, but turning this variable off discourages the planner
-        from using one if there are other methods available. The
-        default is on.
-       
-      
-     
-
-     
-      enable_sort (boolean)
-      
-       enable_sort configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of explicit sort
-        steps. It's not possible to suppress explicit sorts entirely,
-        but turning this variable off discourages the planner from
-        using one if there are other methods available. The default
-        is on.
-       
-      
-     
-
-     
-      enable_tidscan (boolean)
-      
-       enable_tidscan configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of TID
-        scan plan types. The default is on.
-       
-      
-     
-     
-     
-     
-     
-     
-      Planner Cost Constants
-     
-
-   
-    
-     Unfortunately, there is no well-defined method for determining
-     ideal values for the family of cost variables that
-     appear below. You are encouraged to experiment and share
-     your findings.
-    
-   
-
-     
-     
-     
-      effective_cache_size (floating point)
-      
-       effective_cache_size configuration parameter
-      
-      
-       
-        Sets the planner's assumption about the effective size of the
-        disk cache that is available to a single index scan.  This is
-        factored into estimates of the cost of using an index; a higher
-        value makes it more likely index scans will be used, a lower
-        value makes it more likely sequential scans will be used. When
-        setting this parameter you should consider both
-        PostgreSQL's shared buffers and the
-        portion of the kernel's disk cache that will be used for
-        PostgreSQL data files.  Also, take into
-        account the expected number of concurrent queries using different
-        indexes, since they will have to share the available space.
-        This parameter has no effect on the size of shared memory
-        allocated by PostgreSQL, nor does it reserve kernel disk cache;
-        it is used only for estimation purposes.
-        The value is measured in disk pages, which are
-        normally 8192 bytes each. The default is 1000.
-       
-      
-     
-
-     
-      random_page_cost (floating point)
-      
-       random_page_cost configuration parameter
-      
-      
-       
-        Sets the planner's estimate of the cost of a
-        nonsequentially fetched disk page. This is measured as a
-        multiple of the cost of a sequential page fetch. A higher
-        value makes it more likely a sequential scan will be used, a
-        lower value makes it more likely an index scan will be
-        used. The default is four.
-       
-      
-     
-
-     
-      cpu_tuple_cost (floating point)
-      
-       cpu_tuple_cost configuration parameter
-      
-      
-       
-        Sets the planner's estimate of the cost of processing
-        each row during a query. This is measured as a fraction of
-        the cost of a sequential page fetch. The default is 0.01.
-       
-      
-     
-
-     
-      cpu_index_tuple_cost (floating point)
-      
-       cpu_index_tuple_cost configuration parameter
-      
-      
-       
-        Sets the planner's estimate of the cost of processing
-        each index row during an index scan. This is measured as a
-        fraction of the cost of a sequential page fetch. The default
-        is 0.001.
-       
-      
-     
-    
-     
-      cpu_operator_cost (floating point)
-      
-       cpu_operator_cost configuration parameter
-      
-      
-       
-        Sets the planner's estimate of the cost of processing each
-        operator in a WHERE clause. This is measured as a fraction of
-        the cost of a sequential page fetch. The default is 0.0025.
-       
-      
-     
-
-     
-
-    
-     
-     Genetic Query Optimizer
-
-     
-
-     
-      
-       genetic query optimization
-      
-      
-       GEQO
-       genetic query optimization
-      
-      
-       geqo configuration parameter
-      
-      geqo (boolean)
-      
-       
-        Enables or disables genetic query optimization, which is an
-        algorithm that attempts to do query planning without
-        exhaustive searching. This is on by default. The
-        geqo_threshold variable provides a more
-        granular way to disable GEQO for certain classes of queries.
-       
-      
-     
-
-     
-      geqo_threshold (integer)
-      
-       geqo_threshold configuration parameter
-      
-      
-       
-        Use genetic query optimization to plan queries with at least
-        this many FROM items involved. (Note that an outer
-        JOIN construct counts as only one FROM
-        item.) The default is 12. For simpler queries it is usually best
-        to use the deterministic, exhaustive planner, but for queries with
-        many tables the deterministic planner takes too long.
-       
-      
-     
-
-     
-      geqo_effort
-      (integer)
-      
-       geqo_effort configuration parameter
-      
-      
-       
-        Controls the trade off between planning time and query plan
-        efficiency in GEQO. This variable must be an integer in the
-        range from 1 to 10. The default value is 5. Larger values
-        increase the time spent doing query planning, but also
-        increase the likelihood that an efficient query plan will be
-        chosen.
-       
-
-       
-        geqo_effort doesn't actually do anything
-        directly; it is only used to compute the default values for
-        the other variables that influence GEQO behavior (described
-        below). If you prefer, you can set the other parameters by
-        hand instead.
-       
-      
-     
-
-     
-      geqo_pool_size (integer)
-      
-       geqo_pool_size configuration parameter
-      
-      
-       
-        Controls the pool size used by GEQO. The pool size is the
-        number of individuals in the genetic population.  It must be
-        at least two, and useful values are typically 100 to 1000.  If
-        it is set to zero (the default setting) then a suitable
-        default is chosen based on geqo_effort and
-        the number of tables in the query.
-       
-      
-     
-
-     
-      geqo_generations (integer)
-      
-       geqo_generations configuration parameter
-      
-      
-       
-        Controls the number of generations used by GEQO.  Generations
-        specifies the number of iterations of the algorithm.  It must
-        be at least one, and useful values are in the same range as
-        the pool size.  If it is set to zero (the default setting)
-        then a suitable default is chosen based on
-        geqo_pool_size.
-       
-      
-     
-
-     
-      geqo_selection_bias (floating point)
-      
-       geqo_selection_bias configuration parameter
-      
-      
-       
-        Controls the selection bias used by GEQO. The selection bias
-        is the selective pressure within the population. Values can be
-        from 1.50 to 2.00; the latter is the default.
-       
-      
-     
-     
-     
-    
-     
-     Other Planner Options
-
-     
-
-     
-      default_statistics_target (integer)
-      
-       default_statistics_target configuration parameter
-      
-      
-       
-        Sets the default statistics target for table columns that have
-        not had a column-specific target set via ALTER TABLE
-        SET STATISTICS.  Larger values increase the time needed to
-        do ANALYZE, but may improve the quality of the
-        planner's estimates. The default is 10. For more information
-        on the use of statistics by the PostgreSQL
-        query planner, refer to .
-       
-      
-     
-
-     
-      constraint_exclusion (boolean)
-      
-       constraint exclusion
-      
-      
-       constraint_exclusion configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of table constraints to
-        limit table access.  The default is off.
-       
-
-       
-        When this parameter is on, the planner compares query
-        conditions with table CHECK constraints, and omits scanning tables
-        where the conditions contradict the constraints.  (Presently
-        this is done only for child tables of inheritance scans.)  For
-        example:
-
-
-CREATE TABLE parent(key integer, ...);
-CREATE TABLE child1000(check (key between 1000 and 1999)) INHERITS(parent);
-CREATE TABLE child2000(check (key between 2000 and 2999)) INHERITS(parent);
-...
-SELECT * FROM parent WHERE key = 2400;
-
-
-        With constraint exclusion enabled, this SELECT will not scan
-        child1000 at all.  This can improve performance when
-        inheritance is used to build partitioned tables.
-       
-
-       
-        Currently, constraint_exclusion defaults to
-        off, because it risks incorrect results if
-        query plans are cached --- if a table constraint is changed or dropped,
-        the previously generated plan might now be wrong, and there is no
-        built-in mechanism to force re-planning.  (This deficiency will
-        probably be addressed in a future
-        PostgreSQL release.)  Another reason
-        for keeping it off is that the constraint checks are relatively
-        expensive, and in many circumstances will yield no savings.
-        It is recommended to turn this on only if you are actually using
-        partitioned tables designed to take advantage of the feature.
-       
-      
-     
-
-     
-      from_collapse_limit (integer)
-      
-       from_collapse_limit configuration parameter
-      
-      
-       
-        The planner will merge sub-queries into upper queries if the
-        resulting FROM list would have no more than
-        this many items.  Smaller values reduce planning time but may
-        yield inferior query plans.  The default is 8.  It is usually
-        wise to keep this less than .
-       
-      
-     
-
-     
-      join_collapse_limit (integer)
-      
-       join_collapse_limit configuration parameter
-      
-      
-       
-        The planner will rewrite explicit inner JOIN
-        constructs into lists of FROM items whenever a
-        list of no more than this many items in total would
-        result. Prior to PostgreSQL 7.4, joins
-        specified via the JOIN construct would
-        never be reordered by the query planner. The query planner has
-        subsequently been improved so that inner joins written in this
-        form can be reordered; this configuration parameter controls
-        the extent to which this reordering is performed.
-        
-         
-          At present, the order of outer joins specified via the
-          JOIN construct is never adjusted by the query
-          planner; therefore, join_collapse_limit has no
-          effect on this behavior. The planner may be improved to
-          reorder some classes of outer joins in a future release of
-          PostgreSQL.
-         
-        
-       
-
-       
-        By default, this variable is set the same as
-        from_collapse_limit, which is appropriate
-        for most uses. Setting it to 1 prevents any reordering of
-        inner JOINs. Thus, the explicit join order
-        specified in the query will be the actual order in which the
-        relations are joined. The query planner does not always choose
-        the optimal join order; advanced users may elect to
-        temporarily set this variable to 1, and then specify the join
-        order they desire explicitly. Another consequence of setting
-        this variable to 1 is that the query planner will behave more
-        like the PostgreSQL 7.3 query
-        planner, which some users might find useful for backward
-        compatibility reasons.
-       
-
-       
-        Setting this variable to a value between 1 and
-        from_collapse_limit might be useful to
-        trade off planning time against the quality of the chosen plan
-        (higher values produce better plans).
-       
-      
-     
-     
-     
-    
-   
-
-   
-    Error Reporting and Logging
-
-    
-     server log
-    
-
-    
-     Where to log
-
-     
-      where to log
-     
-
-     
-
-     
-      log_destination (string)
-      
-       log_destination configuration parameter
-      
-      
-       
-        PostgreSQL supports several methods
-         for logging server messages, including
-         stderr and
-         syslog. On Windows, 
-         eventlog is also supported. Set this
-         option to a list of desired log destinations separated by
-         commas. The default is to log to stderr 
-         only.
-         This option can only be set at server start or in the
-         postgresql.conf configuration file.
-       
-      
-     
-
-     
-      redirect_stderr (boolean)
-      
-       redirect_stderr configuration parameter
-      
-      
-       
-         This option allows messages sent to stderr to be
-         captured and redirected into log files.
-         This option, in combination with logging to stderr,
-         is often more useful than
-         logging to syslog, since some types of messages
-         may not appear in syslog output (a common example
-         is dynamic-linker failure messages).
-         This option can only be set at server start.
-       
-      
-     
-
-     
-      log_directory (string)
-      
-       log_directory configuration parameter
-      
-      
-       
-        When redirect_stderr is enabled, this option
-        determines the directory in which log files will be created.
-        It may be specified as an absolute path, or relative to the
-        cluster data directory.
-        This option can only be set at server start or in the
-        postgresql.conf configuration file.
-       
-      
-     
-
-     
-      log_filename (string)
-      
-       log_filename configuration parameter
-      
-      
-       
-        When redirect_stderr is enabled, this option
-        sets the file names of the created log files.  The value
-        is treated as a strftime pattern,
-        so %-escapes
-        can be used to specify time-varying file names.
-        If no %-escapes are present,
-        PostgreSQL will
-        append the epoch of the new log file's open time.  For example,
-        if log_filename were server_log, then the
-        chosen file name would be server_log.1093827753
-        for a log starting at Sun Aug 29 19:02:33 2004 MST.
-        This option can only be set at server start or in the
-        postgresql.conf configuration file.
-       
-      
-     
-
-     
-      log_rotation_age (integer)
-      
-       log_rotation_age configuration parameter
-      
-      
-       
-        When redirect_stderr is enabled, this option
-        determines the maximum lifetime of an individual log file.
-        After this many minutes have elapsed, a new log file will
-        be created.  Set to zero to disable time-based creation of
-        new log files.
-        This option can only be set at server start or in the
-        postgresql.conf configuration file.
-       
-      
-     
-
-     
-      log_rotation_size (integer)
-      
-       log_rotation_size configuration parameter
-      
-      
-       
-        When redirect_stderr is enabled, this option
-        determines the maximum size of an individual log file.
-        After this many kilobytes have been emitted into a log file,
-        a new log file will be created.  Set to zero to disable size-based
-        creation of new log files.
-        This option can only be set at server start or in the
-        postgresql.conf configuration file.
-       
-      
-     
-
-     
-      log_truncate_on_rotation (boolean)
-      
-       log_truncate_on_rotation configuration parameter
-      
-      
-       
-        When redirect_stderr is enabled, this option will cause
-        PostgreSQL to truncate (overwrite),
-        rather than append to, any existing log file of the same name.
-        However, truncation will occur only when a new file is being opened
-        due to time-based rotation, not during server startup or size-based
-        rotation.  When off, pre-existing files will be appended to in
-        all cases.  For example, using this option in combination with
-        a log_filename like postgresql-%H.log
-        would result in generating twenty-four hourly log files and then
-        cyclically overwriting them.
-        This option can only be set at server start or in the
-        postgresql.conf configuration file.
-       
-       
-        Example:  To keep 7 days of logs, one log file per day named
-        server_log.Mon, server_log.Tue, 
-        etc, and automatically overwrite last week's log with this week's log,
-        set log_filename to server_log.%a, 
-        log_truncate_on_rotation to on, and 
-        log_rotation_age to 1440.
-       
-       
-        Example: To keep 24 hours of logs, one log file per hour, but 
-        also rotate sooner if the log file size exceeds 1GB, set 
-        log_filename to server_log.%H%M, 
-        log_truncate_on_rotation to on, 
-        log_rotation_age to 60, and 
-        log_rotation_size to 1000000.
-        Including %M in log_filename allows
-        any size-driven rotations that may occur to select a filename
-        different from the hour's initial filename.
-       
-      
-     
-
-     
-      syslog_facility (string)
-      
-       syslog_facility configuration parameter
-      
-      
-       
-        When logging to syslog is enabled, this option
-        determines the syslog
-        facility to be used.  You may choose
-        from LOCAL0, LOCAL1,
-        LOCAL2, LOCAL3, LOCAL4,
-        LOCAL5, LOCAL6, LOCAL7;
-        the default is LOCAL0. See also the
-        documentation of your system's
-        syslog daemon.
-        This option can only be set at server start.
-       
-      
-     
-     
-     
-      syslog_ident (string)
-      
-       syslog_identity configuration parameter
-      
-       
-        
-         When logging to syslog is enabled, this option
-         determines the program name used to identify
-         PostgreSQL messages in
-         syslog logs. The default is
-         postgres.
-          This option can only be set at server start.
-        
-       
-      
-      
-      
-    
-     
-     When To Log
-
-     
-
-     
-      client_min_messages (string)
-      
-       client_min_messages configuration parameter
-      
-      
-       
-        Controls which message levels are sent to the client.
-        Valid values are DEBUG5,
-        DEBUG4, DEBUG3, DEBUG2,
-        DEBUG1, LOG, NOTICE,
-        WARNING, and ERROR.  Each level
-        includes all the levels that follow it.  The later the level,
-        the fewer messages are sent.  The default is
-        NOTICE.  Note that LOG has a different
-        rank here than in log_min_messages.
-       
-      
-     
-
-     
-      log_min_messages (string)
-      
-       log_min_messages configuration parameter
-      
-      
-       
-        Controls which message levels are written to the server log.
-        Valid values are DEBUG5, DEBUG4,
-        DEBUG3, DEBUG2, DEBUG1,
-        INFO, NOTICE, WARNING,
-        ERROR, LOG, FATAL, and
-        PANIC.  Each level includes all the levels that
-        follow it.  The later the level, the fewer messages are sent
-        to the log.  The default is NOTICE.  Note that
-        LOG has a different rank here than in
-        client_min_messages.
-        Only superusers can change this setting.
-       
-      
-     
-
-     
-      log_error_verbosity (string)
-      
-       log_error_verbosity configuration parameter
-      
-      
-       
-        Controls the amount of detail written in the server log for each
-        message that is logged.  Valid values are TERSE,
-        DEFAULT, and VERBOSE, each adding more
-        fields to displayed messages.
-        Only superusers can change this setting.
-       
-      
-     
-
-     
-      log_min_error_statement (string)
-      
-       log_min_error_statement configuration parameter
-      
-      
-       
-        Controls whether or not the SQL statement that causes an error
-        condition will also be recorded in the server log. All SQL
-        statements that cause an error of the specified level or
-        higher are logged.  The default is
-        PANIC (effectively turning this feature
-        off for normal use). Valid values are DEBUG5,
-        DEBUG4, DEBUG3,
-        DEBUG2, DEBUG1,
-        INFO, NOTICE,
-        WARNING, ERROR,
-        FATAL, and PANIC.  For
-        example, if you set this to ERROR then all
-        SQL statements causing errors, fatal errors, or panics will be
-        logged. Enabling this option can be helpful in tracking down
-        the source of any errors that appear in the server log.
-        Only superusers can change this setting.
-       
-      
-     
-     
-     
-      log_min_duration_statement (integer)
-      
-       log_min_duration_statement configuration parameter
-      
-       
-        
-         Logs the statement and its duration on a single log line if its
-         duration is greater than or equal to the specified number of
-         milliseconds. Setting this to zero will print all statements
-         and their durations. Minus-one (the default) disables the
-         feature. For example, if you set it to 250
-         then all SQL statements that run 250ms or longer will be
-         logged. Enabling this option can be useful in tracking down
-         unoptimized queries in your applications. This setting is
-         independent of log_statement and
-         log_duration. Only superusers can change
-         this setting.
-        
-       
-      
-
-     
-      silent_mode (boolean)
-      
-       silent_mode configuration parameter
-      
-      
-       
-        Runs the server silently. If this option is set, the server
-        will automatically run in background and any controlling
-        terminals are disassociated (same effect as
-        postmaster's -S option).
-        The server's standard output and standard error are redirected
-        to /dev/null, so any messages sent to them will be lost.
-        Unless syslog logging is selected or
-        redirect_stderr is enabled, using this option
-        is discouraged because it makes it impossible to see error messages.
-       
-      
-     
-
-     
-
-       
-        Here is a list of the various message severity levels used in
-        these settings:
-        
-         
-          DEBUG[1-5]
-          
-           
-            Provides information for use by developers.
-           
-          
-         
-
-         
-          INFO
-          
-           
-            Provides information implicitly requested by the user,
-            e.g., during VACUUM VERBOSE.
-           
-          
-         
-
-         
-          NOTICE
-          
-           
-            Provides information that may be helpful to users, e.g.,
-            truncation of long identifiers and the creation of indexes as part
-            of primary keys.
-           
-          
-         
-
-         
-          WARNING
-          
-           
-            Provides warnings to the user, e.g., COMMIT
-            outside a transaction block.
-           
-          
-         
-
-         
-          ERROR
-          
-           
-            Reports an error that caused the current command to abort.
-           
-          
-         
-
-         
-          LOG
-          
-           
-            Reports information of interest to administrators, e.g.,
-            checkpoint activity.
-           
-          
-         
-
-         
-          FATAL
-          
-           
-            Reports an error that caused the current session to abort.
-           
-          
-         
-
-         
-          PANIC
-          
-           
-            Reports an error that caused all sessions to abort.
-           
-          
-         
-        
-       
-
-    
-     
-     What To Log
-
-     
-
-     
-      debug_print_parse (boolean)
-      debug_print_rewritten (boolean)
-      debug_print_plan (boolean)
-      debug_pretty_print (boolean)
-      
-       debug_print_parse configuration parameter
-      
-      
-       debug_print_rewritten configuration parameter
-      
-      
-       debug_print_plan configuration parameter
-      
-      
-       debug_pretty_print configuration parameter
-      
-      
-       
-        These options enable various debugging output to be emitted.
-        For each executed query, they print
-        the resulting parse tree, the query rewriter output, or the
-        execution plan.  debug_pretty_print indents
-        these displays to produce a more readable but much longer
-        output format.  client_min_messages or
-        log_min_messages must be
-        DEBUG1 or lower to actually send this output
-        to the client or the server log, respectively.
-        These options are off by default.
-       
-      
-     
-
-     
-      log_connections (boolean)
-      
-       log_connections configuration parameter
-      
-      
-       
-        This outputs a line to the server log detailing each successful
-        connection. This is off by default, although it is probably very
-        useful. This option can only be set at server start or in the
-        postgresql.conf configuration file.
-       
-      
-     
-
-     
-      log_disconnections (boolean)
-      
-       log_disconnections configuration parameter
-      
-      
-       
-        This outputs a line in the server log similar to
-        log_connections but at session termination,
-        and includes the duration of the session.  This is off by
-        default. This option can only be set at server start or in the
-        postgresql.conf configuration file.
-       
-      
-     
-
-
-     
-      log_duration (boolean)
-      
-       log_duration configuration parameter
-      
-      
-       
-        Causes the duration of every completed statement which satisfies
-        log_statement to be logged.  When using this option, 
-        if you are not using syslog, it is recommended 
-        that you log the PID or session ID using log_line_prefix 
-        so that you can link the statement to the 
-        duration using the process ID or session ID. The default is
-        off. Only superusers can change this setting.
-       
-      
-     
-     
-     
-      log_line_prefix (string)
-      
-       log_line_prefix configuration parameter
-      
-      
-       
-         This is a printf-style string that is output at the
-         beginning of each log line. The default is an empty string.
-         Each recognized escape is replaced as outlined 
-         below - anything else that looks like an escape is ignored. Other
-         characters are copied straight to the log line. Some escapes are
-         only recognised by session processes, and do not apply to
-         background processes such as the postmaster. Syslog
-         produces its own 
-         time stamp and process ID information, so you probably do not want to
-         use those escapes if you are using syslog.
-         This option can only be set at server start or in the
-         postgresql.conf configuration file.
-
-         
-          
-           
-            
-             Escape
-             Effect
-             Session only
-             
-            
-           
-            
-             %u
-             User name
-             yes
-            
-            
-             %d
-             Database name
-             yes
-            
-            
-             %r
-             Remote host name or IP address, and remote port
-             yes
-            
-            
-             %h
-             Remote Hostname or IP address
-             yes
-            
-            
-             %p
-             Process ID
-             no
-            
-            
-             %t
-             Time stamp (no milliseconds)
-             no
-            
-            
-             %m
-             Time stamp with milliseconds
-             no
-            
-            
-             %i
-             Command tag: This is the command that generated the log line.
-             yes
-            
-            
-             %c
-             Session ID: A unique identifier for each session.
-             It is 2 4-byte hexadecimal numbers (without leading zeros) 
-             separated by a dot. The numbers
-             are the session start time and the process ID, so this can also
-             be used as a space saving way of printing these items.
-             yes
-            
-            
-             %l
-             Number of the log line for each process, starting at 1
-             no
-            
-            
-             %s
-             Session start time stamp
-             yes
-            
-            
-             %x
-             Transaction ID
-             yes
-            
-            
-             %q
-             Does not produce any output, but tells non-session
-             processes to stop at this point in the string. Ignored by
-             session processes.
-             no
-            
-            
-             %%
-             Literal %
-             no
-            
-           
-          
-         
-       
-      
-     
-
-     
-      log_statement (string)
-      
-       log_statement configuration parameter
-      
-      
-       
-        Controls which SQL statements are logged. Valid values are
-        none, ddl, mod, and
-        all. ddl logs all data definition
-        commands like CREATE, ALTER, and
-        DROP commands. mod logs all
-        ddl statements, plus INSERT,
-        UPDATE, DELETE, TRUNCATE,
-        and COPY FROM. PREPARE and
-        EXPLAIN ANALYZE statements are also logged if their
-        contained command is of an appropriate type.
-       
-       
-        The default is none. Only superusers can change this
-        setting.
-       
-
-       
-        
-         The EXECUTE statement is not considered a
-         ddl or mod statement.  When it is logged, 
-         only the name of the prepared statement is reported, not the
-         actual prepared statement.
-        
-
-        
-         When a function is defined in the
-         PL/pgSQLserver-side language, any queries
-         executed by the function will only be logged the first time that the
-         function is invoked in a particular session. This is because
-         PL/pgSQL keeps a cache of the
-         query plans produced for the SQL statements in the function.
-        
-       
-      
-     
-
-     
-      log_hostname (boolean)
-      
-       log_hostname configuration parameter
-      
-      
-       
-        By default, connection log messages only show the IP address of the
-        connecting host. Turning on this option causes logging of the
-        host name as well.  Note that depending on your host name resolution
-        setup this might impose a non-negligible performance penalty. This
-        option can only be set at server start or in the
-        postgresql.conf file.
-       
-      
-     
-
-     
-    
-   
-
-   
-    Runtime Statistics
-
-    
-     Statistics Monitoring
-     
-
-     
-      log_statement_stats (boolean)
-      log_parser_stats (boolean)
-      log_planner_stats (boolean)
-      log_executor_stats (boolean)
-      
-       log_statement_stats configuration parameter
-      
-      
-       log_parser_stats configuration parameter
-      
-      
-       log_planner_stats configuration parameter
-      
-      
-       log_executor_stats configuration parameter
-      
-      
-       
-        For each query, write performance statistics of the respective
-        module to the server log. This is a crude profiling
-        instrument.  log_statement_stats reports total
-        statement statistics, while the others report per-module statistics.
-        log_statement_stats cannot be enabled together with
-        any of the per-module options.  All of these options are disabled by
-        default.   Only superusers can change these settings.
-       
-      
-     
-
-     
-
-    
-    
-     Query and Index Statistics Collector
-     
-
-     
-      stats_start_collector (boolean)
-      
-       stats_start_collector configuration parameter
-      
-      
-       
-        Controls whether the server should start the
-        statistics-collection subprocess.  This is on by default, but
-        may be turned off if you know you have no interest in
-        collecting statistics.  This option can only be set at server
-        start.
-       
-      
-     
-
-     
-      stats_command_string (boolean)
-      
-       stats_command_string configuration parameter
-      
-      
-       
-        Enables the collection of statistics on the currently
-        executing command of each session, along with the time at
-        which that command began execution. This option is off by
-        default. Note that even when enabled, this information is not
-        visible to all users, only to superusers and the user owning
-        the session being reported on; so it should not represent a
-        security risk. This data can be accessed via the
-        pg_stat_activity system view; refer
-        to  for more information.
-       
-      
-     
-
-     
-      stats_block_level (boolean)
-      
-       stats_block_level configuration parameter
-      
-      
-       
-        Enables the collection of block-level statistics on database
-        activity. This option is disabled by default. If this option
-        is enabled, the data that is produced can be accessed via the
-        pg_stat and
-        pg_statio family of system views;
-        refer to  for more information.
-       
-      
-     
-
-     
-      stats_row_level (boolean)
-      
-       stats_row_level configuration parameter
-      
-      
-       
-        Enables the collection of row-level statistics on database
-        activity. This option is disabled by default. If this option
-        is enabled, the data that is produced can be accessed via the
-        pg_stat and
-        pg_statio family of system views;
-        refer to  for more information.
-       
-      
-     
-
-     
-      stats_reset_on_server_start (boolean)
-      
-       stats_reset_on_server_start configuration parameter
-      
-      
-       
-        If on, collected statistics are zeroed out whenever the server
-        is restarted. If off, statistics are accumulated across server
-        restarts. The default is off. This option can only 
-        be set at server start.
-       
-      
-     
-
-     
-    
-   
-
-   
-    Automatic Vacuuming
-
-     
-      Beginning in PostgreSQL 8.1, there is an optional server
-      process called the autovacuum daemon, whose purpose is
-      to automate the issuance of periodic VACUUM and
-      ANALYZE commands.  When enabled, the autovacuum daemon
-      runs periodically and checks for tables that have had a large number
-      of updated or deleted tuples.  This check uses the row-level statistics
-      collection facility; therefore, the autovacuum daemon cannot be used
-      unless  and
-       are set TRUE.  Also, it's
-      important to allow a slot for the autovacuum process when choosing
-      the value of .
-     
-
-    
-
-     
-      autovacuum (boolean)
-      
-       autovacuum configuration parameter
-      
-      
-       
-        Controls whether the server should start the
-        autovacuum subprocess.  This is off by default.
-        This option can only be set at server start or in the
-        postgresql.conf file.
-       
-      
-     
-
-     
-      autovacuum_naptime (integer)
-      
-       autovacuum_naptime configuration parameter
-      
-      
-       
-        Specifies the delay between activity rounds for the autovacuum
-        subprocess.  In each round the subprocess examines one database
-        and issues VACUUM and ANALYZE commands
-        as needed for tables in that database.  The delay is measured
-        in seconds, and the default is 60.
-        This option can only be set at server start or in the
-        postgresql.conf file.
-       
-      
-     
-
-     
-      autovacuum_vacuum_threshold (integer)
-      
-       autovacuum_vacuum_threshold configuration parameter
-      
-      
-       
-        Specifies the minimum number of updated or deleted tuples needed
-        to trigger a VACUUM in any one table.
-        The default is 1000.
-        This option can only be set at server start or in the
-        postgresql.conf file.
-       
-      
-     
-
-     
-      autovacuum_analyze_threshold (integer)
-      
-       autovacuum_analyze_threshold configuration parameter
-      
-      
-       
-        Specifies the minimum number of inserted, updated or deleted tuples
-        needed to trigger an ANALYZE in any one table.
-        The default is 500.
-        This option can only be set at server start or in the
-        postgresql.conf file.
-       
-      
-     
-
-     
-      autovacuum_vacuum_scale_factor (floating point)
-      
-       autovacuum_vacuum_scale_factor configuration parameter
-      
-      
-       
-        Specifies a fraction of the table size to add to
-        autovacuum_vacuum_threshold
-        when deciding whether to trigger a VACUUM.
-        The default is 0.4.
-        This option can only be set at server start or in the
-        postgresql.conf file.
-       
-      
-     
-
-     
-      autovacuum_analyze_scale_factor (floating point)
-      
-       autovacuum_analyze_scale_factor configuration parameter
-      
-      
-       
-        Specifies a fraction of the table size to add to
-        autovacuum_analyze_threshold
-        when deciding whether to trigger an ANALYZE.
-        The default is 0.2.
-        This option can only be set at server start or in the
-        postgresql.conf file.
-       
-      
-     
-
-     
-      autovacuum_vacuum_cost_delay (integer)
-      
-       autovacuum_vacuum_cost_delay configuration parameter
-      
-      
-       
-        Specifies the cost delay value that will be used in automatic
-        VACUUM operations.  If -1 is specified (which is the
-        default), the regular
-         value will be used.
-        This setting can be overridden for individual tables by entries in
-        pg_autovacuum.
-       
-      
-     
-
-     
-      autovacuum_vacuum_cost_limit (integer)
-      
-       autovacuum_vacuum_cost_limit configuration parameter
-      
-      
-       
-        Specifies the cost limit value that will be used in automatic
-        VACUUM operations.  If -1 is specified (which is the
-        default), the regular
-         value will be used.
-        This setting can be overridden for individual tables by entries in
-        pg_autovacuum.
-       
-      
-     
-
-    
-   
-
-   
-    Client Connection Defaults
-
-    
-     Statement Behavior
-     
-
-     
-      search_path (string)
-      
-       search_path configuration parameter
-      
-      pathfor schemas
-      
-       
-        This variable specifies the order in which schemas are searched
-        when an object (table, data type, function, etc.) is referenced by a
-        simple name with no schema component.  When there are objects of
-        identical names in different schemas, the one found first
-        in the search path is used.  An object that is not in any of the
-        schemas in the search path can only be referenced by specifying
-        its containing schema with a qualified (dotted) name.
-       
-
-       
-        The value for search_path has to be a comma-separated
-        list of schema names.  If one of the list items is
-        the special value $user, then the schema
-        having the name returned by SESSION_USER is substituted, if there
-        is such a schema.  (If not, $user is ignored.)
-       
-
-       
-        The system catalog schema, pg_catalog, is always
-        searched, whether it is mentioned in the path or not.  If it is
-        mentioned in the path then it will be searched in the specified
-        order.  If pg_catalog is not in the path then it will
-        be searched before searching any of the path items.
-        It should also be noted that the temporary-table schema,
-        pg_temp_nnn, is implicitly searched before any of
-        these.
-       
-
-       
-        When objects are created without specifying a particular target
-        schema, they will be placed in the first schema listed
-        in the search path.  An error is reported if the search path is
-        empty.
-       
-
-       
-        The default value for this parameter is
-        '$user, public' (where the second part will be
-        ignored if there is no schema named public).
-        This supports shared use of a database (where no users
-        have private schemas, and all share use of public),
-        private per-user schemas, and combinations of these.  Other
-        effects can be obtained by altering the default search path
-        setting, either globally or per-user.
-       
-
-       
-        The current effective value of the search path can be examined
-        via the SQL function
-        current_schemas().  This is not quite the same as
-        examining the value of search_path, since
-        current_schemas() shows how the requests
-        appearing in search_path were resolved.
-       
-
-       
-        For more information on schema handling, see .
-       
-      
-     
-
-     
-      default_tablespace (string)
-      
-       default_tablespace configuration parameter
-      
-      tablespacedefault
-      
-       
-        This variable specifies the default tablespace in which to create
-        objects (tables and indexes) when a CREATE command does
-        not explicitly specify a tablespace.
-       
-
-       
-        The value is either the name of a tablespace, or an empty string
-        to specify using the default tablespace of the current database.
-        If the value does not match the name of any existing tablespace,
-        PostgreSQL will automatically use the default
-        tablespace of the current database.
-       
-
-       
-        For more information on tablespaces,
-        see .
-       
-      
-     
-
-     
-      check_function_bodies (boolean)
-      
-       check_function_bodies configuration parameter
-      
-      
-       
-        This parameter is normally on. When set to off, it
-        disables validation of the function body string during 
-        linkend="sql-createfunction"
-        endterm="sql-createfunction-title">. Disabling validation is
-        occasionally useful to avoid problems such as forward references
-        when restoring function definitions from a dump.
-       
-      
-     
-
-     
-      
-       transaction isolation level
-      
-      
-       default_transaction_isolation configuration parameter
-      
-      default_transaction_isolation (string)
-      
-       
-        Each SQL transaction has an isolation level, which can be
-        either read uncommitted, read
-        committed, repeatable read, or
-        serializable.  This parameter controls the
-        default isolation level of each new transaction. The default
-        is read committed.
-       
-
-       
-        Consult  and 
-        linkend="sql-set-transaction"
-        endterm="sql-set-transaction-title"> for more information.
-       
-      
-     
-
-     
-      
-       read-only transaction
-      
-      
-       default_transaction_read_only configuration parameter
-      
-
-      default_transaction_read_only (boolean)
-      
-       
-        A read-only SQL transaction cannot alter non-temporary tables.
-        This parameter controls the default read-only status of each new
-        transaction. The default is off (read/write).
-       
-
-       
-        Consult 
-        endterm="sql-set-transaction-title"> for more information.
-       
-      
-     
-     
-     
-      statement_timeout (integer)
-      
-       statement_timeout configuration parameter
-      
-      
-       
-        Abort any statement that takes over the specified number of
-        milliseconds.  A value of zero (the default) turns off the limitation.
-       
-      
-     
-     
-     
-    
-     
-     Locale and Formatting
-
-     
-
-     
-      DateStyle (string)
-      
-       DateStyle configuration parameter
-      
-      
-       
-        Sets the display format for date and time values, as well as the
-        rules for interpreting ambiguous date input values. For
-        historical reasons, this variable contains two independent
-        components: the output format specification (ISO,
-        Postgres, SQL, or German)
-        and the input/output specification for year/month/day ordering
-        (DMY, MDY, or YMD). These
-        can be set separately or together. The keywords Euro
-        and European are synonyms for DMY; the
-        keywords US, NonEuro, and
-        NonEuropean are synonyms for MDY. See
-         for more information. The
-        default is ISO, MDY.
-       
-      
-     
-
-     
-      timezone (string)
-      
-       timezone configuration parameter
-      
-      time zone
-      
-       
-        Sets the time zone for displaying and interpreting time
-        stamps.  The default is 'unknown', which means to use whatever 
-        the system environment specifies as the time zone.  See 
-        linkend="datatype-datetime"> for more information.
-       
-      
-     
-
-     
-      australian_timezones (boolean)
-      
-       australian_timezones configuration parameter
-      
-      time zoneAustralian
-      
-       
-        If set to on, ACST,
-        CST, EST, and
-        SAT are interpreted as Australian time
-        zones rather than as North/South American time zones and
-        Saturday. The default is off.
-       
-      
-     
-
-     
-      
-       significant digits
-      
-      
-       floating-point
-       display
-      
-      
-       extra_float_digits configuration parameter
-      
-
-      extra_float_digits (integer)
-      
-       
-        This parameter adjusts the number of digits displayed for
-        floating-point values, including float4, float8,
-        and geometric data types.  The parameter value is added to the
-        standard number of digits (FLT_DIG or DBL_DIG
-        as appropriate).  The value can be set as high as 2, to include
-        partially-significant digits; this is especially useful for dumping
-        float data that needs to be restored exactly.  Or it can be set
-        negative to suppress unwanted digits.
-       
-      
-     
-
-     
-      client_encoding (string)
-      
-       client_encoding configuration parameter
-      
-      character set
-      
-       
-        Sets the client-side encoding (character set).
-        The default is to use the database encoding.
-       
-      
-     
-
-     
-      lc_messages (string)
-      
-       lc_messages configuration parameter
-      
-      
-       
-        Sets the language in which messages are displayed.  Acceptable
-        values are system-dependent; see  for
-        more information.  If this variable is set to the empty string
-        (which is the default) then the value is inherited from the
-        execution environment of the server in a system-dependent way.
-       
-
-       
-        On some systems, this locale category does not exist.  Setting
-        this variable will still work, but there will be no effect.
-        Also, there is a chance that no translated messages for the
-        desired language exist.  In that case you will continue to see
-        the English messages.
-       
-      
-     
-
-     
-      lc_monetary (string)
-      
-       lc_monetary configuration parameter
-      
-      
-       
-        Sets the locale to use for formatting monetary amounts, for
-        example with the to_char family of
-        functions.  Acceptable values are system-dependent; see 
-        linkend="locale"> for more information.  If this variable is
-        set to the empty string (which is the default) then the value
-        is inherited from the execution environment of the server in a
-        system-dependent way.
-       
-      
-     
-
-     
-      lc_numeric (string)
-      
-       lc_numeric configuration parameter
-      
-      
-       
-        Sets the locale to use for formatting numbers, for example
-        with the to_char family of
-        functions. Acceptable values are system-dependent; see 
-        linkend="locale"> for more information.  If this variable is
-        set to the empty string (which is the default) then the value
-        is inherited from the execution environment of the server in a
-        system-dependent way.
-       
-      
-     
-
-     
-      lc_time (string)
-      
-       lc_time configuration parameter
-      
-      
-       
-        Sets the locale to use for formatting date and time values.
-        (Currently, this setting does nothing, but it may in the
-        future.)  Acceptable values are system-dependent; see 
-        linkend="locale"> for more information.  If this variable is
-        set to the empty string (which is the default) then the value
-        is inherited from the execution environment of the server in a
-        system-dependent way.
-       
-      
-     
-
-     
-
-    
-     
-     Other Defaults
-
-     
-
-     
-      explain_pretty_print (boolean)
-      
-       explain_pretty_print configuration parameter
-      
-      
-       
-        Determines whether EXPLAIN VERBOSE uses the
-        indented or non-indented format for displaying detailed
-        query-tree dumps. The default is on.
-       
-      
-     
-
-     
-      dynamic_library_path (string)
-      
-       dynamic_library_path configuration parameter
-      
-      dynamic loading
-      
-       
-        If a dynamically loadable module needs to be opened and the
-        file name specified in the CREATE FUNCTION or
-        LOAD command
-        does not have a directory component (i.e. the
-        name does not contain a slash), the system will search this
-        path for the required file.
-       
-
-       
-        The value for dynamic_library_path has to be a
-        list of absolute directory paths separated by colons (or semi-colons
-        on Windows).  If a list element starts
-        with the special string $libdir, the
-        compiled-in PostgreSQL package
-        library directory is substituted for $libdir. This
-        is where the modules provided by the standard
-        PostgreSQL distribution are installed.
-        (Use pg_config --pkglibdir to find out the name of
-        this directory.) For example:
-
-dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
-
-        or, in a Windows environment:
-
-dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
-
-       
-
-       
-        The default value for this parameter is
-        '$libdir'. If the value is set to an empty
-        string, the automatic path search is turned off.
-       
-
-       
-        This parameter can be changed at run time by superusers, but a
-        setting done that way will only persist until the end of the
-        client connection, so this method should be reserved for
-        development purposes. The recommended way to set this parameter
-        is in the postgresql.conf configuration
-        file.
-       
-      
-     
-
-     
-    
-   
-
-   
-    Lock Management
-
-     
-
-     
-      
-       deadlock
-       timeout during
-      
-      
-       timeout
-       deadlock
-      
-      
-       deadlock_timeout configuration parameter
-      
-
-      deadlock_timeout (integer)
-      
-       
-        This is the amount of time, in milliseconds, to wait on a lock
-        before checking to see if there is a deadlock condition. The
-        check for deadlock is relatively slow, so the server doesn't run
-        it every time it waits for a lock. We (optimistically?) assume
-        that deadlocks are not common in production applications and
-        just wait on the lock for a while before starting the check for a
-        deadlock. Increasing this value reduces the amount of time
-        wasted in needless deadlock checks, but slows down reporting of
-        real deadlock errors. The default is 1000 (i.e., one second),
-        which is probably about the smallest value you would want in
-        practice. On a heavily loaded server you might want to raise it.
-        Ideally the setting should exceed your typical transaction time,
-        so as to improve the odds that a lock will be released before
-        the waiter decides to check for deadlock.
-       
-      
-     
-
-     
-      max_locks_per_transaction (integer)
-      
-       max_locks_per_transaction configuration parameter
-      
-      
-       
-        The shared lock table is created with room to describe locks on
-        max_locks_per_transaction *
-        ( +
-        ) objects;
-        hence, no more than this many distinct objects can
-        be locked at any one time. (Thus, this parameter's name may be
-        confusing: it is not a hard limit on the number of locks taken
-        by any one transaction, but rather a maximum average value.)
-        The default, 64, has historically
-        proven sufficient, but you might need to raise this value if you
-        have clients that touch many different tables in a single
-        transaction. This option can only be set at server start.
-       
-
-       
-        Increasing this parameter may cause PostgreSQL
-        to request more System V shared
-        memory than your operating system's default configuration
-        allows. See  for information on how to
-        adjust those parameters, if necessary.
-       
-      
-     
-
-     
-   
-
-   
-    Version and Platform Compatibility
-
-    
-     Previous PostgreSQL Versions
-     
-
-     
-      add_missing_from (boolean)
-      FROMmissing
-      
-       add_missing_from configuration parameter
-      
-      
-       
-        When on, tables that are referenced by a query will be
-        automatically added to the FROM clause if not
-        already present. This behavior does not comply with the SQL
-        standard and many people dislike it because it can mask mistakes
-        (such as referencing a table where you should have referenced
-        its alias). The default is off. This variable can be
-        enabled for compatibility with releases of
-        PostgreSQL prior to 8.1, where this behavior was
-        allowed by default.
-       
-
-       
-        Note that even when this variable is enabled, a warning
-        message will be emitted for each implicit FROM
-        entry referenced by a query. Users are encouraged to update
-        their applications to not rely on this behavior, by adding all
-        tables referenced by a query to the query's FROM
-        clause (or its USING clause in the case of
-        DELETE).
-       
-      
-     
-
-     
-      regex_flavor (string)
-      regular expressions
-      
-       regex_flavor configuration parameter
-      
-      
-       
-        The regular expression flavor can be set to
-        advanced, extended, or basic.
-        The default is advanced.  The extended
-        setting may be useful for exact backwards compatibility with
-        pre-7.4 releases of PostgreSQL.  See
-         for details.
-       
-      
-     
-
-     
-      sql_inheritance (boolean)
-      
-       sql_inheritance configuration parameter
-      
-      inheritance
-      
-       
-        This controls the inheritance semantics, in particular whether
-        subtables are included by various commands by default. They were
-        not included in versions prior to 7.1. If you need the old
-        behavior you can set this variable to off, but in
-        the long run you are encouraged to change your applications to
-        use the ONLY key word to exclude subtables.
-        See  for more information about
-        inheritance.
-       
-      
-     
-
-     
-      default_with_oids (boolean)
-      
-       default_with_oids configuration parameter
-      
-      
-       
-        This controls whether CREATE TABLE and
-        CREATE TABLE AS include an OID column in
-        newly-created tables, if neither WITH OIDS
-        nor WITHOUT OIDS is specified. It also
-        determines whether OIDs will be included in tables created by
-        SELECT INTO. In PostgreSQL
-        8.1 default_with_oids is disabled by default; in
-        prior versions of PostgreSQL, it was on by default.
-       
-
-       
-        The use of OIDs in user tables is considered deprecated, so
-        most installations should leave this variable disabled.
-        Applications that require OIDs for a particular table should
-        specify WITH OIDS when creating the
-        table. This variable can be enabled for compatibility with old
-        applications that do not follow this behavior.
-       
-      
-     
-
-     
-      escape_string_warning (boolean)
-      stringsescape
-      
-       escape_string_warning configuration parameter
-      
-      
-       
-        When on, a warning is issued if a backslash (\)
-        appears in an ordinary string literal ('...'
-        syntax). The default is off.
-       
-       
-        Escape string syntax (E'...') should be used for
-        escapes, because in future versions of
-        PostgreSQL ordinary strings will have
-        the standard-conforming behavior of treating backslashes
-        literally.
-       
-      
-     
-
-     
-    
-    
-     Platform and Client Compatibility
-     
-
-     
-      transform_null_equals (boolean)
-      IS NULL
-      
-       transform_null_equals configuration parameter
-      
-      
-       
-        When on, expressions of the form expr =
-        NULL (or NULL =
-        expr) are treated as
-        expr IS NULL, that is, they
-        return true if expr evaluates to the null value,
-        and false otherwise. The correct SQL-spec-compliant behavior of
-        expr = NULL is to always
-        return null (unknown). Therefore this option defaults to
-        off.
-       
-
-       
-        However, filtered forms in Microsoft
-        Access generate queries that appear to use
-        expr = NULL to test for
-        null values, so if you use that interface to access the database you
-        might want to turn this option on.  Since expressions of the
-        form expr = NULL always
-        return the null value (using the correct interpretation) they are not
-        very useful and do not appear often in normal applications, so
-        this option does little harm in practice.  But new users are
-        frequently confused about the semantics of expressions
-        involving null values, so this option is not on by default.
-       
-
-       
-        Note that this option only affects the exact form = NULL,
-        not other comparison operators or other expressions
-        that are computationally equivalent to some expression
-        involving the equals operator (such as IN).
-        Thus, this option is not a general fix for bad programming.
-       
-
-       
-        Refer to  for related information.
-       
-      
-     
-
-     
-    
-   
-
-   
-    Preset Options
-
-    
-     The following parameters are read-only, and are determined
-     when PostgreSQL is compiled or when it is
-     installed. As such, they have been excluded from the sample
-     postgresql.conf file.  These options report
-     various aspects of PostgreSQL behavior
-     that may be of interest to certain applications, particularly
-     administrative front-ends.
-    
-
-    
-
-     
-      block_size (integer)
-      
-       block_size configuration parameter
-      
-      
-       
-        Reports the size of a disk block.  It is determined by the value
-        of BLCKSZ when building the server. The default
-        value is 8192 bytes.  The meaning of some configuration
-        variables (such as ) is
-        influenced by block_size. See 
-        linkend="runtime-config-resource"> for information.
-       
-      
-     
-
-     
-      integer_datetimes (boolean)
-      
-       integer_datetimes configuration parameter
-      
-      
-       
-        Reports whether PostgreSQL was built
-        with support for 64-bit-integer dates and times.  It is set by
-        configuring with --enable-integer-datetimes
-        when building PostgreSQL.  The
-        default value is off.
-       
-      
-     
-
-     
-      lc_collate (string)
-      
-       lc_collate configuration parameter
-      
-      
-       
-        Reports the locale in which sorting of textual data is done.
-        See  for more information.
-        The value is determined when the database cluster is initialized.
-       
-      
-     
-
-     
-      lc_ctype (string)
-      
-       lc_ctype configuration parameter
-      
-      
-       
-        Reports the locale that determines character classifications.
-        See  for more information.
-        The value is determined when the database cluster is initialized.
-        Ordinarily this will be the same as lc_collate,
-        but for special applications it might be set differently.
-       
-      
-     
-
-     
-      max_function_args (integer)
-      
-       max_function_args configuration parameter
-      
-      
-       
-        Reports the maximum number of function arguments. It is determined by
-        the value of FUNC_MAX_ARGS when building the server. The
-        default value is 100.
-       
-      
-     
-
-     
-      max_identifier_length (integer)
-      
-       max_identifier_length configuration parameter
-      
-      
-       
-        Reports the maximum identifier length. It is determined as one
-        less than the value of NAMEDATALEN when building
-        the server. The default value of NAMEDATALEN is
-        64; therefore the default
-        max_identifier_length is 63.
-       
-      
-     
-
-     
-      max_index_keys (integer)
-      
-       max_index_keys configuration parameter
-      
-      
-       
-        Reports the maximum number of index keys. It is determined by
-        the value of INDEX_MAX_KEYS when building the server. The
-        default value is 32.
-       
-      
-     
-
-     
-      server_encoding (string)
-      
-       server_encoding configuration parameter
-      
-      character set
-      
-       
-        Reports the database encoding (character set).
-        It is determined when the database is created.  Ordinarily,
-        clients need only be concerned with the value of 
-        linkend="guc-client-encoding">.
-       
-      
-     
-
-     
-      server_version (string)
-      
-       server_version configuration parameter
-      
-      
-       
-        Reports the version number of the server. It is determined by the
-        value of PG_VERSION when building the server.
-       
-      
-     
-
-     
-      standard_conforming_strings (boolean)
-      stringsescape
-      
-       standard_conforming_strings configuration parameter
-      
-      
-       
-        Reports whether ordinary string literals
-        ('...') treat backslashes literally, as specified in
-        the SQL standard.  The value is currently always off,
-        indicating that backslashes are treated as escapes.  It is planned
-        that this will change to on in a future
-        PostgreSQL release when string literal
-        syntax changes to meet the standard.  Applications may check this
-        parameter to determine how string literals will be processed.
-        The presence of this parameter can also be taken as an indication
-        that the escape string syntax (E'...') is supported.
-       
-      
-     
-
-    
-   
-
-   
-    Customized Options
-
-    
-     This feature was designed to allow options not normally known to
-     PostgreSQL to be added by add-on modules
-     (such as procedural languages).  This allows add-on modules to be
-     configured in the standard ways.
-    
-
-    
-
-     
-      custom_variable_classes (string)
-      
-       custom_variable_classes configuration parameter
-      
-      
-       
-        This variable specifies one or several class names to be used for
-        custom variables, in the form of a comma-separated list. A custom
-        variable is a variable not normally known
-        to PostgreSQL proper but used by some
-        add-on module.  Such variables must have names consisting of a class
-        name, a dot, and a variable name.  custom_variable_classes
-        specifies all the class names in use in a particular installation.
-        This option can only be set at server start or in the
-        postgresql.conf configuration file.
-       
-
-      
-     
-    
-
-    
-     The difficulty with setting custom variables in
-     postgresql.conf is that the file must be read before add-on
-     modules have been loaded, and so custom variables would ordinarily be
-     rejected as unknown.  When custom_variable_classes is set,
-     the server will accept definitions of arbitrary variables within each
-     specified class.  These variables will be treated as placeholders and
-     will have no function until the module that defines them is loaded. When a
-     module for a specific class is loaded, it will add the proper variable
-     definitions for its class name, convert any placeholder
-     values according to those definitions, and issue warnings for any
-     placeholders of its class that remain (which presumably would be
-     misspelled configuration variables).
-    
-
-    
-     Here is an example of what postgresql.conf might contain
-     when using custom variables:
-
-
-custom_variable_classes = 'plr,plperl'
-plr.path = '/usr/lib/R'
-plperl.use_strict = true
-plruby.use_strict = true        # generates error: unknown class name
-
-    
-   
-
-   
-    Developer Options
-
-    
-     The following options are intended for work on the
-     PostgreSQL source, and in some cases
-     to assist with recovery of severely damaged databases.  There
-     should be no reason to use them in a production database setup.
-     As such, they have been excluded from the sample
-     postgresql.conf file.  Note that many of these
-     options require special source compilation flags to work at all.
-    
-
-    
-     
-      debug_assertions (boolean)
-      
-       debug_assertions configuration parameter
-      
-      
-       
-        Turns on various assertion checks. This is a debugging aid. If
-        you are experiencing strange problems or crashes you might want
-        to turn this on, as it might expose programming mistakes. To use
-        this option, the macro USE_ASSERT_CHECKING
-        must be defined when PostgreSQL is
-        built (accomplished by the configure option
-        --enable-cassert). Note that
-        debug_assertions defaults to on
-        if PostgreSQL has been built with
-        assertions enabled.
-       
-      
-     
-
-     
-      pre_auth_delay (integer)
-      
-       pre_auth_delay configuration parameter
-      
-      
-       
-        If nonzero, a delay of this many seconds occurs just after a new
-        server process is forked, before it conducts the authentication
-        process.  This is intended to give an opportunity to attach to the
-        server process with a debugger to trace down misbehavior in
-        authentication.
-       
-      
-     
-
-     
-      trace_notify (boolean)
-      
-       trace_notify configuration parameter
-      
-      
-       
-        Generates a great amount of debugging output for the
-        LISTEN and NOTIFY
-        commands.   or
-         must be
-        DEBUG1 or lower to send this output to the
-        client or server log, respectively.
-       
-      
-     
-
-     
-      trace_locks (boolean)
-      trace_lwlocks (boolean)
-      trace_userlocks (boolean)
-      trace_lock_oidmin (boolean)
-      trace_lock_table (boolean)
-      debug_deadlocks (boolean)
-      log_btree_build_stats (boolean)
-      
-       
-        Various other code tracing and debugging options.
-       
-      
-     
-
-     
-      wal_debug (boolean)
-      
-       wal_debug configuration parameter
-      
-      
-       
-        If on, emit WAL-related debugging output. This option is
-        only available if the WAL_DEBUG macro was
-        defined when PostgreSQL was
-        compiled.
-       
-      
-     
-
-    
-      zero_damaged_pages (boolean)
-      
-       zero_damaged_pages configuration parameter
-      
-      
-       
-        Detection of a damaged page header normally causes
-        PostgreSQL to report an error, aborting the current
-        command.  Setting zero_damaged_pages to on causes
-        the system to instead report a warning, zero out the damaged page,
-        and continue processing.  This behavior will destroy data,
-        namely all the rows on the damaged page.  But it allows you to get
-        past the error and retrieve rows from any undamaged pages that may
-        be present in the table.  So it is useful for recovering data if
-        corruption has occurred due to hardware or software error.  You should
-        generally not set this on until you have given up hope of recovering
-        data from the damaged page(s) of a table.  The
-        default setting is off, and it can only be changed
-        by a superuser.
-       
-      
-     
-   
-  
-  
-   Short Options
-
-   
-    For convenience there are also single letter command-line option switches
-    available for some parameters. They are described in 
-    linkend="runtime-config-short-table">.
-   
-
-    
-     Short option key
-     
-      
-       
-        Short option
-        Equivalent
-       
-      
-
-      
-       
-        -B x
-        shared_buffers = x
-       
-       
-        -d x
-        log_min_messages = DEBUGx
-       
-       
-        -F
-        fsync = off
-       
-       
-        -h x
-        listen_addresses = x
-       
-       
-        -i
-        listen_addresses = '*'
-       
-       
-        -k x
-        unix_socket_directory = x
-       
-       
-        -l
-        ssl = on
-       
-       
-        -N x
-        max_connections = x
-       
-       
-        -p x
-        port = x
-       
-
-       
-        
-          -fb, -fh, -fi,
-          -fm, -fn,
-          -fs, -ft
-          id="fn.runtime-config-short">
-           
-            For historical reasons, these options must be passed to
-            the individual server process via the -o
-            postmaster option, for example,
-
-$ postmaster -o '-S 1024 -s'
-
-            or via PGOPTIONS from the client side, as
-            explained above.
-           
-          
-         
-         
-          enable_bitmapscan = off,
-          enable_hashjoin = off,
-          enable_indexscan = off,
-          enable_mergejoin = off,
-          enable_nestloop = off,
-          enable_seqscan = off,
-          enable_tidscan = off
-         
-       
-
-       
-        -s
-        log_statement_stats = on
-       
-
-       
-        -S x
-        
-        work_mem = x
-       
-
-       
-        -tpa, -tpl, -te
-        log_parser_stats = on,
-        log_planner_stats = on, 
-        log_executor_stats = on
-       
-      
-     
-    
-
-  
- 
-
-
  
   Managing Kernel Resources
 




This is the main PostgreSQL git repository.
RSS
Atom



window.onload = function () {
	var tz_cookie = { name: 'gitweb_tz', expires: 14, path: '/' };
	onloadTZSetup('local', tz_cookie, 'datetime');
};

diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index 88487ee93887f2b7c4afd7b729ffa213aa3d9117..3b1cd740057bbd19f3c90d8bee384f9f0ab143cb 100644 (file)
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -1,4 +1,4 @@
-
+
 
 
 
@@ -41,6 +41,7 @@
 
 
 
+
 
 
 

diff --git a/doc/src/sgml/postgres.sgml b/doc/src/sgml/postgres.sgml
index 6fa0e28191b79d99b68921f4ed46475c40fba758..8099f72dd8bb578cf640505080c99d70cd2da914 100644 (file)
--- a/doc/src/sgml/postgres.sgml
+++ b/doc/src/sgml/postgres.sgml
@@ -1,5 +1,5 @@
 
 
 
@@ -146,6 +146,7 @@ $PostgreSQL: pgsql/doc/src/sgml/postgres.sgml,v 1.75 2005/02/27 00:49:28 momjian
   &installation;
   &installw;
   &runtime;
+  &config;
   &user-manag;
   &manage-ag;
   &client-auth;


diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml

index 5af562a6635fecf531be01e97b6be7582e939c9c..3a8745df90955e6ce0736cb85ca6e989e0a84a88 100644 (file)

--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -1,5 +1,5 @@
 
 
 
@@ -451,4224 +451,6 @@ psql: could not connect to server: No such file or directory
    
   
 
-  
-   Run-time Configuration
-
-   
-    configuration
-    of the server
-   
-
-   
-    There are a lot of configuration parameters that affect the
-    behavior of the database system. In this subsection, we describe
-    how to set configuration parameters; the following subsections
-    discuss each parameter in detail.
-   
-
-   
-    All parameter names are case-insensitive. Every parameter takes a
-    value of one of four types: boolean, integer, floating point,
-    or string. Boolean values may be written as ON,
-    OFF, TRUE,
-    FALSE, YES,
-    NO, 1, 0
-    (all case-insensitive) or any unambiguous prefix of these.
-   
-
-   
-    One way to set these parameters is to edit the file
-    postgresql.confpostgresql.conf,
-    which is normally kept in the data directory. (initdb
-    installs a default copy there.) An example of what this file might look
-    like is:
-
-# This is a comment
-log_connections = yes
-log_destination = 'syslog'
-search_path = '$user, public'
-
-    One parameter is specified per line. The equal sign between name and
-    value is optional. Whitespace is insignificant and blank lines are
-    ignored. Hash marks (#) introduce comments
-    anywhere.  Parameter values that are not simple identifiers or
-    numbers must be single-quoted.
-   
-
-   
-    
-     SIGHUP
-    
-    The configuration file is reread whenever the
-    postmaster process receives a
-    SIGHUP signal (which is most easily sent by means
-    of pg_ctl reload). The postmaster
-    also propagates this signal to all currently running server
-    processes so that existing sessions also get the new
-    value. Alternatively, you can send the signal to a single server
-    process directly.  Some parameters can only be set at server start;
-    any changes to their entries in the configuration file will be ignored
-    until the server is restarted.
-   
-
-   
-    A second way to set these configuration parameters is to give them
-    as a command line option to the postmaster, such as:
-
-postmaster -c log_connections=yes -c log_destination='syslog'
-
-    Command-line options override any conflicting settings in
-    postgresql.conf.  Note that this means you won't
-    be able to change the value on-the-fly by editing
-    postgresql.conf, so while the command-line
-    method may be convenient, it can cost you flexibility later.
-   
-
-   
-    Occasionally it is useful to give a command line option to
-    one particular session only. The environment variable
-    PGOPTIONS can be used for this purpose on the
-    client side:
-
-env PGOPTIONS='-c geqo=off' psql
-
-    (This works for any libpq-based client application, not
-    just psql.) Note that this won't work for
-    parameters that are fixed when the server is started or that must be
-    specified in postgresql.conf.
-   
-
-   
-    Furthermore, it is possible to assign a set of option settings to
-    a user or a database.  Whenever a session is started, the default
-    settings for the user and database involved are loaded.  The
-    commands 
-    and ,
-    respectively, are used to configure these settings.  Per-database
-    settings override anything received from the
-    postmaster command-line or the configuration
-    file, and in turn are overridden by per-user settings; both are
-    overridden by per-session options.
-   
-
-   
-    Some parameters can be changed in individual SQL
-    sessions with the 
-    command, for example:
-
-SET ENABLE_SEQSCAN TO OFF;
-
-    If SET is allowed, it overrides all other sources of
-    values for the parameter. Some parameters cannot be changed via
-    SET: for example, if they control behavior that
-    cannot reasonably be changed without restarting
-    PostgreSQL.  Also, some parameters can
-    be modified via SET or ALTER by superusers,
-    but not by ordinary users.
-   
-
-   
-    The 
-    command allows inspection of the current values of all parameters.
-   
-
-   
-    The virtual table pg_settings
-    (described in ) also allows
-    displaying and updating session run-time parameters.  It is equivalent
-    to SHOW and SET, but can be more convenient
-    to use because it can be joined with other tables, or selected from using
-    any desired selection condition.
-   
-    
-   
-    File Locations
-
-     
-      In addition to the postgresql.conf file
-      already mentioned, PostgreSQL uses
-      two other manually-edited configuration files, which control
-      client authentication (their use is discussed in 
-      linkend="client-authentication">).
-      By default, all three configuration files are stored
-      in the database cluster's data directory.  The options described
-      in this subsection allow the configuration files to be placed elsewhere.
-      (Doing so can ease administration.  In particular it is often
-      easier to ensure that the configuration files are properly backed-up
-      when they are kept separate.)
-     
-
-     
-     
-      data_directory (string)
-      
-       data_directory configuration parameter
-      
-      
-       
-         Specifies the directory to use for data storage.
-         This option can only be set at server start.
-       
-      
-     
-
-     
-      config_file (string)
-      
-       config_file configuration parameter
-      
-      
-       
-         Specifies the main server configuration file
-         (customarily called postgresql.conf).
-         This option can only be set on the postmaster command line.
-       
-      
-     
-
-     
-      hba_file (string)
-      
-       hba_file configuration parameter
-      
-      
-       
-         Specifies the configuration file for host-based authentication
-         (customarily called pg_hba.conf).
-         This option can only be set at server start.
-       
-      
-     
-
-     
-      ident_file (string)
-      
-       ident_file configuration parameter
-      
-      
-       
-         Specifies the configuration file for
-         ident authentication
-         (customarily called pg_ident.conf).
-         This option can only be set at server start.
-       
-      
-     
-
-     
-      external_pid_file (string)
-      
-       external_pid_file configuration parameter
-      
-      
-       
-        Specifies the name of an additional process-id (PID) file that the
-        postmaster should create for use by server
-        administration programs.
-        This option can only be set at server start.
-       
-      
-     
-     
-
-     
-      In a default installation, none of the above options are set explicitly.
-      Instead, the
-      data directory is specified by the -D command-line
-      option or the PGDATA environment variable, and the
-      configuration files are all found within the data directory.
-     
-
-     
-      If you wish to keep the configuration files elsewhere than the
-      data directory, the postmaster's -D
-      command-line option or PGDATA environment variable
-      must point to the directory containing the configuration files,
-      and the data_directory option must be set in
-      postgresql.conf (or on the command line) to show
-      where the data directory is actually located.  Notice that
-      data_directory overrides -D and
-      PGDATA for the location
-      of the data directory, but not for the location of the configuration
-      files.
-     
-
-     
-      If you wish, you can specify the configuration file names and locations
-      individually using the options config_file,
-      hba_file and/or ident_file.
-      config_file can only be specified on the 
-      postmaster command line, but the others can be
-      set within the main configuration file.  If all three options plus
-      data_directory are explicitly set, then it is not necessary
-      to specify -D or PGDATA.
-     
-
-     
-      When setting any of these options, a relative path will be interpreted
-      with respect to the directory in which the postmaster
-      is started.
-     
-   
-
-   
-    Connections and Authentication
-
-    
-     Connection Settings
-
-     
-
-     
-      listen_addresses (string)
-      
-       listen_addresses configuration parameter
-      
-      
-       
-         Specifies the TCP/IP address(es) on which the server is
-         to listen for connections from client applications.  
-         The value takes the form of a comma-separated list of host names
-         and/or numeric IP addresses.  The special entry *
-         corresponds to all available IP interfaces.
-         If the list is empty, the server does not listen on any IP interface
-         at all, in which case only Unix-domain sockets can be used to connect
-         to it.
-         The default value is localhost,
-         which allows only local loopback connections to be made.
-         This parameter can only be set at server start.
-       
-      
-     
-
-     
-      port (integer)
-      
-       port configuration parameter
-      
-      
-       
-        The TCP port the server listens on; 5432 by default.  Note that the
-        same port number is used for all IP addresses the server listens on.
-        This parameter can only be set at server start.
-       
-      
-     
-
-     
-      max_connections (integer)
-      
-       max_connections configuration parameter
-      
-      
-       
-        Determines the maximum number of concurrent connections to the
-        database server. The default is typically 100, but may be less
-        if your kernel settings will not support it (as determined
-        during initdb).  This parameter can only be
-        set at server start.
-       
-
-       
-        Increasing this parameter may cause PostgreSQL
-        to request more System V shared
-        memory or semaphores than your operating system's default configuration
-        allows. See  for information on how to
-        adjust those parameters, if necessary.
-       
-      
-     
-     
-     
-     xreflabel="superuser_reserved_connections">
-      superuser_reserved_connections
-      (integer)
-      
-       superuser_reserved_connections configuration parameter
-      
-      
-       
-        Determines the number of connection slots that
-        are reserved for connections by PostgreSQL
-        superusers.  At most 
-        connections can ever be active simultaneously.  Whenever the
-        number of active concurrent connections is at least
-        max_connections minus
-        superuser_reserved_connections, new
-        connections will be accepted only for superusers.
-       
-
-       
-        The default value is 2. The value must be less than the value of
-        max_connections. This parameter can only be
-        set at server start.
-       
-      
-     
-
-     
-      unix_socket_directory (string)
-      
-       unix_socket_directory configuration parameter
-      
-      
-       
-        Specifies the directory of the Unix-domain socket on which the
-        server is to listen for
-        connections from client applications.  The default is normally
-        /tmp, but can be changed at build time.
-        This parameter can only be set at server start.
-       
-      
-     
-
-     
-      unix_socket_group (string)
-      
-       unix_socket_group configuration parameter
-      
-      
-       
-        Sets the owning group of the Unix-domain socket.  (The owning
-        user of the socket is always the user that starts the
-        server.)  In combination with the option
-        unix_socket_permissions this can be used as
-        an additional access control mechanism for Unix-domain connections.
-        By default this is the empty string, which uses the default
-        group for the current user.  This option can only be set at
-        server start.
-       
-      
-     
-
-     
-      unix_socket_permissions (integer)
-      
-       unix_socket_permissions configuration parameter
-      
-      
-       
-        Sets the access permissions of the Unix-domain socket.  Unix-domain
-        sockets use the usual Unix file system permission set.
-        The option value is expected to be a numeric mode
-        specification in the form accepted by the
-        chmod and umask
-        system calls.  (To use the customary octal format the number
-        must start with a 0 (zero).)
-       
-
-       
-        The default permissions are 0777, meaning
-        anyone can connect. Reasonable alternatives are
-        0770 (only user and group, see also
-        unix_socket_group) and 0700
-        (only user). (Note that for a Unix-domain socket, only write
-        permission matters and so there is no point in setting or revoking
-        read or execute permissions.)
-       
-
-       
-        This access control mechanism is independent of the one
-        described in .
-       
-
-       
-        This option can only be set at server start.
-       
-      
-     
-     
-     
-      bonjour_name (string)
-      
-       bonjour_name configuration parameter
-      
-      
-       
-        Specifies the Bonjour broadcast
-        name.  By default, the computer name is used, specified as an
-        empty string ''.  This option is ignored if the server was not
-        compiled with Bonjour support.  This
-        option can only be set at server start.
-       
-      
-     
-     
-     
-      tcp_keepalives_idle (integer)
-      
-       tcp_keepalives_idle configuration parameter
-      
-      
-       
-        On systems that support the TCP_KEEPIDLE socket option, specifies the
-        number of seconds between sending keepalives on an otherwise idle
-        connection. A value of 0 uses the system default. If TCP_KEEPIDLE is
-        not supported, this parameter must be 0. This option is ignored for
-        connections made via a Unix-domain socket.
-       
-      
-     
-     
-     
-      tcp_keepalives_interval (integer)
-      
-       tcp_keepalives_interval configuration parameter
-      
-      
-       
-        On systems that support the TCP_KEEPINTVL socket option, specifies how
-        long, in seconds, to wait for a response to a keepalive before
-        retransmitting. A value of 0 uses the system default. If TCP_KEEPINTVL
-        is not supported, this parameter must be 0. This option is ignored
-        for connections made via a Unix-domain socket.
-       
-      
-     
-     
-     
-      tcp_keepalives_count (integer)
-      
-       tcp_keepalives_count configuration parameter
-      
-      
-       
-        On systems that support the TCP_KEEPCNT socket option, specifies how
-        many keepalives may be lost before the connection is considered dead. 
-        A value of 0 uses the system default. If TCP_KEEPINTVL is not
-        supported, this parameter must be 0.
-       
-      
-     
-     
-     
-     
-     
-     Security and Authentication
-     
-     
-     
-      authentication_timeout (integer)
-      timeoutclient authentication
-      client authenticationtimeout during
-      
-       authentication_timeout configuration parameter
-      
-
-      
-       
-        Maximum time to complete client authentication, in seconds. If a
-        would-be client has not completed the authentication protocol in
-        this much time, the server breaks the connection. This prevents
-        hung clients from occupying a connection indefinitely. This
-        option can only be set at server start or in the
-        postgresql.conf file. The default is 60.
-       
-      
-     
-     
-     
-      ssl (boolean)
-      
-       ssl configuration parameter
-      
-      
-       
-        Enables SSL connections. Please read
-         before using this. The default
-        is off. This parameter can only be set at server
-        start.
-       
-      
-     
-
-     
-      password_encryption (boolean)
-      
-       password_encryption configuration parameter
-      
-      
-       
-        When a password is specified in 
-        linkend="sql-createuser" endterm="sql-createuser-title"> or
-        
-        without writing either ENCRYPTED or
-        UNENCRYPTED, this option determines whether the
-        password is to be encrypted. The default is on
-        (encrypt the password).
-       
-      
-     
-
-     
-      krb_server_keyfile (string)
-      
-       krb_server_keyfile configuration parameter
-      
-      
-       
-        Sets the location of the Kerberos server key file. See
-         for details. This parameter
-        can only be set at server start.
-       
-      
-     
-
-     
-      krb_srvname (string)
-      
-       krb_srvname configuration parameter
-      
-      
-       
-        Sets the Kerberos service name. See 
-        for details.  This parameter can only be set at server start.
-       
-      
-     
-
-     
-      krb_server_hostname (string)
-      
-       krb_server_hostname configuration parameter
-      
-      
-       
-        Sets the hostname part of the service principal.
-        This, combined with krb_srvname, is used to generate
-        the complete service principal, i.e.
-        krb_server_hostname/krb_server_hostname@REALM.
-       
-       
-        If not set, the default is to allow any service principal matching an entry
-        in the keytab.  See  for details.
-        This parameter can only be set at server start.
-       
-      
-     
-
-     
-      krb_caseins_users (boolean)
-      
-       krb_caseins_users configuration parameter
-      
-      
-       
-        Sets if Kerberos usernames should be treated case-insensitively.
-        The default is off (case sensitive). This parameter
-        can only be set at server start.
-       
-      
-     
-
-     
-      db_user_namespace (boolean)
-      
-       db_user_namespace configuration parameter
-      
-      
-       
-        This enables per-database user names.  It is off by default.
-       
-
-       
-        If this is on, you should create users as username@dbname.
-        When username is passed by a connecting client,
-        @ and the database name are appended to the user
-        name and that database-specific user name is looked up by the
-        server. Note that when you create users with names containing
-        @ within the SQL environment, you will need to
-        quote the user name.
-       
-
-       
-        With this option enabled, you can still create ordinary global
-        users.  Simply append @ when specifying the user
-        name in the client.  The @ will be stripped off
-        before the user name is looked up by the server.
-       
-
-       
-        
-         This feature is intended as a temporary measure until a
-         complete solution is found.  At that time, this option will
-         be removed.
-        
-       
-      
-     
-
-    
-    
-   
-
-   
-    Resource Consumption
-
-    
-     Memory
-
-     
-     
-      shared_buffers (integer)
-      
-       shared_buffers configuration parameter
-      
-      
-       
-        Sets the number of shared memory buffers used by the database
-        server. The default is typically 1000, but may be less if your
-        kernel settings will not support it (as determined during
-        initdb).  Each buffer is 8192 bytes, unless a
-        different value of BLCKSZ was chosen when building
-        the server.  This setting must be at least 16, as well as at
-        least twice the value of ;
-        however, settings significantly higher than the minimum are
-        usually needed for good performance.  Values of a few thousand
-        are recommended for production installations.  This option can
-        only be set at server start.
-       
-
-       
-        Increasing this parameter may cause PostgreSQL
-        to request more System V shared
-        memory than your operating system's default configuration
-        allows. See  for information on how to
-        adjust those parameters, if necessary.
-       
-      
-     
-
-     
-      temp_buffers (integer)
-      
-       temp_buffers configuration parameter
-      
-      
-       
-        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 1000.  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.
-       
-
-       
-        A session will allocate temporary buffers as needed up to the limit
-        given by temp_buffers.  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 temp_buffers.  However if a buffer is
-        actually used an additional 8192 bytes will be consumed for it
-        (or in general, BLCKSZ bytes).
-       
-      
-     
-
-     
-      max_prepared_transactions (integer)
-      
-       max_prepared_transactions configuration parameter
-      
-      
-       
-        Sets the maximum number of transactions that can be in the
-        prepared state simultaneously (see 
-        linkend="sql-prepare-transaction"
-        endterm="sql-prepare-transaction-title">).
-        Setting this parameter to zero disables the prepared-transaction
-        feature.
-        The default is 5.
-        This option can only be set at server start.
-       
-
-       
-        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 max_prepared_transactions to be at least
-        as large as , to avoid unwanted
-        failures at the prepare step.
-       
-
-       
-        Increasing this parameter may cause PostgreSQL
-        to request more System V shared
-        memory than your operating system's default configuration
-        allows. See  for information on how to
-        adjust those parameters, if necessary.
-       
-      
-     
-
-     
-      work_mem (integer)
-      
-       work_mem configuration parameter
-      
-      
-       
-        Specifies the amount of memory to be used by internal sort operations
-        and hash tables before switching to temporary disk files. The value is
-        specified in kilobytes, and defaults to 1024 kilobytes (1 MB).
-        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 work_mem; it is necessary to
-        keep this fact in mind when choosing the value. Sort operations are
-        used for ORDER BY, DISTINCT, and
-        merge joins.
-        Hash tables are used in hash joins, hash-based aggregation, and
-        hash-based processing of IN subqueries.
-       
-      
-     
-     
-     
-      maintenance_work_mem (integer)
-      
-       maintenance_work_mem configuration parameter
-      
-      
-       
-        Specifies the maximum amount of memory to be used in maintenance
-        operations, such as VACUUM, CREATE
-        INDEX, and ALTER TABLE ADD FOREIGN KEY.
-        The value is specified in kilobytes, and defaults to 16384 kilobytes
-        (16 MB).  Since only one of these operations can be executed at 
-        a time by a database session, and an installation normally doesn't
-        have very many of them happening concurrently, it's safe to set this
-        value significantly larger than work_mem.  Larger
-        settings may improve performance for vacuuming and for restoring
-        database dumps.
-       
-      
-     
-
-     
-      max_stack_depth (integer)
-      
-       max_stack_depth configuration parameter
-      
-      
-       
-        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 ulimit -s 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.  Setting the parameter higher than
-        the actual kernel limit will mean that a runaway recursive function
-        can crash an individual backend process.  The default setting is
-        2048 KB (two megabytes), which is conservatively small and unlikely
-        to risk crashes.  However, it may be too small to allow execution
-        of complex functions.
-       
-      
-     
-
-     
-     
-     
-     Free Space Map
-
-     
-      free space map
-     
-
-     
-      These parameters control the size of the shared free space
-      map, 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 PostgreSQL
-      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 VACUUM VERBOSE 
-      command can help in determining if the current settings are adequate.
-      A NOTICE message is also printed during such an operation
-      if the current settings are too low.
-     
-
-     
-      Increasing these parameters may cause PostgreSQL
-      to request more System V shared
-      memory than your operating system's default configuration
-      allows. See  for information on how to
-      adjust those parameters, if necessary.
-     
-
-     
-     
-      max_fsm_pages (integer)
-      
-       max_fsm_pages configuration parameter
-      
-      
-       
-        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 more than
-        16 * max_fsm_relations.  The default is 20000.
-        This option can only be set at server start.
-       
-      
-     
-
-     
-      max_fsm_relations (integer)
-      
-       max_fsm_relations configuration parameter
-      
-      
-       
-        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 1000.
-        This option can only be set at server start.
-       
-      
-     
-     
-     
-     
-     
-     Kernel Resource Usage
-     
-
-     
-      max_files_per_process (integer)
-      
-       max_files_per_process configuration parameter
-      
-      
-       
-        Sets the maximum number of simultaneously open files allowed to each
-        server subprocess. The default is 1000. 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 Too many open
-        files failures, try reducing this setting.
-        This option can only be set at server start.
-       
-      
-     
-     
-     
-      preload_libraries (string)
-      
-       preload_libraries configuration parameter
-      
-      
-       
-        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
-        '$libdir/mylib:mylib_init' would cause
-        mylib to be preloaded and mylib_init
-        to be executed. If more than one library is to be loaded,
-        separate their names with commas.
-       
-
-       
-        If a specified library or initialization function is not found,
-        the server will fail to start.
-       
-
-       
-        PostgreSQL procedural language
-        libraries may be preloaded in this way, typically by using the
-        syntax '$libdir/plXXX:plXXX_init' where
-        XXX is pgsql, perl,
-        tcl, or python.
-       
-
-       
-        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.
-       
-      
-     
-
-     
-    
-
-    
-     
-       Cost-Based Vacuum Delay
-     
-
-     
-      During the execution of 
-      endterm="sql-vacuum-title"> and 
-      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
-      vacuum_cost_limit), the process performing
-      the operation will sleep for a while (specified by
-      vacuum_cost_delay). Then it will reset the
-      counter and continue execution.
-     
-
-     
-      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
-      VACUUM and ANALYZE 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.
-     
-
-     
-      This feature is disabled by default. To enable it, set the
-      vacuum_cost_delay variable to a nonzero
-      value.
-     
-
-     
-      
-       vacuum_cost_delay (integer)
-       
-        vacuum_cost_delay configuration parameter
-       
-       
-        
-         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
-         vacuum_cost_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.
-        
-       
-      
-
-      
-       vacuum_cost_page_hit (integer)
-       
-        vacuum_cost_page_hit configuration parameter
-       
-       
-        
-         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.
-        
-       
-      
-
-      
-       vacuum_cost_page_miss (integer)
-       
-        vacuum_cost_page_miss configuration parameter
-       
-       
-        
-         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.
-        
-       
-      
-
-      
-       vacuum_cost_page_dirty (integer)
-       
-        vacuum_cost_page_dirty configuration parameter
-       
-       
-        
-         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.
-        
-       
-      
-
-      
-       vacuum_cost_limit (integer)
-       
-        vacuum_cost_limit configuration parameter
-       
-       
-        
-         The accumulated cost that will cause the vacuuming process to sleep.
-         The default value is 200.
-        
-       
-      
-     
-
-     
-      
-       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 vacuum_cost_delay *
-       accumulated_balance /
-       vacuum_cost_limit with a maximum of
-       vacuum_cost_delay * 4.
-      
-     
-
-    
-
-    
-     Background Writer
-
-     
-      Beginning in PostgreSQL 8.0, there is a separate server
-      process called the background writer, whose sole function
-      is to issue writes of 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 section can be used to tune
-      the behavior for local needs.
-     
-
-     
-      
-       bgwriter_delay (integer)
-       
-        bgwriter_delay configuration parameter
-       
-       
-        
-         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 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 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 only be set at server start or in the
-         postgresql.conf file.
-        
-       
-      
-
-      
-       bgwriter_lru_percent (floating point)
-       
-        bgwriter_lru_percent configuration parameter
-       
-       
-        
-         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
-         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 only be set at server start or in the
-         postgresql.conf file.
-        
-       
-      
-
-      
-       bgwriter_lru_maxpages (integer)
-       
-        bgwriter_lru_maxpages configuration parameter
-       
-       
-        
-         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 only be set at server start or in the
-         postgresql.conf file.
-        
-       
-      
-
-      
-       bgwriter_all_percent (floating point)
-       
-        bgwriter_all_percent configuration parameter
-       
-       
-        
-         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
-         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 bgwriter_delay
-         setting, this will allow the entire shared buffer pool to be scanned
-         about once per minute.
-         This option can only be set at server start or in the
-         postgresql.conf file.
-        
-       
-      
-
-      
-       bgwriter_all_maxpages (integer)
-       
-        bgwriter_all_maxpages configuration parameter
-       
-       
-        
-         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 only be set at server start or in the
-         postgresql.conf file.
-        
-       
-      
-     
-
-     
-      Smaller values of bgwriter_all_percent and
-      bgwriter_all_maxpages 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 bgwriter_lru_percent and
-      bgwriter_lru_maxpages 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 maxpages values and/or both
-      percent values to zero.
-     
-    
-
-   
-
-   
-    Write Ahead Log
-
-   
-    See also  for details on WAL
-    tuning.
-   
-
-    
-     Settings
-     
-     
-     
-      
-       fsync configuration parameter
-      
-      fsync (boolean)
-      
-       
-        If this option is on, the PostgreSQL server
-        will use the fsync() system call in several places
-        to make sure that updates are physically written to disk. This
-        insures that a database cluster will recover to a
-        consistent state after an operating system or hardware crash.
-       
-
-       
-        However, using fsync() results in a
-        performance penalty: when a transaction is committed,
-        PostgreSQL must wait for the
-        operating system to flush the write-ahead log to disk.  When
-        fsync is disabled, the operating system is
-        allowed to do its best in buffering, ordering, and delaying
-        writes. This can result in significantly improved performance.
-        However, if the system crashes, the results of the last few
-        committed transactions may be lost in part or whole. In the
-        worst case, unrecoverable data corruption may occur.
-        (Crashes of the database server itself are not
-        a risk factor here.  Only an operating-system-level crash
-        creates a risk of corruption.)
-       
-
-       
-        Due to the risks involved, there is no universally correct
-        setting for fsync. Some administrators
-        always disable fsync, while others only
-        turn it off for bulk loads, where there is a clear restart
-        point if something goes wrong, whereas some administrators
-        always leave fsync enabled. The default is
-        to enable fsync, for maximum reliability.
-        If you trust your operating system, your hardware, and your
-        utility company (or your battery backup), you can consider
-        disabling fsync.
-       
-
-       
-        This option can only be set at server start or in the
-        postgresql.conf file.  If this option
-        is off, consider also turning off 
-        guc-full-page-writes.
-       
-      
-     
-     
-     
-      wal_sync_method (string)
-      
-       wal_sync_method configuration parameter
-      
-      
-       
-        Method used for forcing WAL updates out to disk.  Possible
-        values are:
-       
-       
-        
-        
-         open_datasync (write WAL files with open() option O_DSYNC)
-        
-        
-        
-        
-         fdatasync (call fdatasync() at each commit),
-        
-        
-        
-        
-         fsync (call fsync() at each commit)
-        
-        
-        
-        
-         fsync_writethrough (force write-through of any disk write cache)
-        
-        
-        
-        
-         open_sync (write WAL files with open() option O_SYNC)
-        
-        
-       
-       
-        Not all of these choices are available on all platforms.
-        The top-most supported option is used as the default.
-        If fsync is off then this setting is irrelevant.
-        This option can only be set at server start or in the
-        postgresql.conf file.
-       
-      
-     
-     
-     
-      
-       full_page_writes configuration parameter
-      
-      full_page_writes (boolean)
-      
-       
-        A page write in process during an operating system crash might
-        be only partially written to disk, leading to an on-disk page
-        that contains a mix of old and new data. During recovery, the
-        row changes stored in WAL are not enough to completely restore
-        the page.
-       
-
-       
-        When this option is on, the PostgreSQL server
-        writes full pages to WAL when they are first modified after a
-        checkpoint so full recovery is possible. Turning this option off
-        might lead to a corrupt system after an operating system crash
-        or power failure because uncorrected partial pages might contain
-        inconsistent or corrupt data. The risks are less but similar to
-        fsync.
-       
-
-       
-        This option can only be set at server start or in the
-        postgresql.conf file.  The default is
-        on.
-       
-      
-     
-     
-     
-      wal_buffers (integer)
-      
-       wal_buffers configuration parameter
-      
-      
-       
-        Number of disk-page buffers allocated in shared memory for WAL data.
-        The default is 8.  The setting need only be large enough to hold
-        the amount of WAL data generated by one typical transaction, since
-        the data is flushed to disk at every transaction commit.
-        This option can only be set at server start.
-       
-
-       
-        Increasing this parameter may cause PostgreSQL
-        to request more System V shared
-        memory than your operating system's default configuration
-        allows. See  for information on how to
-        adjust those parameters, if necessary.
-       
-      
-     
-                
-     
-      commit_delay (integer)
-      
-       commit_delay configuration parameter
-      
-      
-       
-        Time delay between writing a commit record to the WAL buffer
-        and flushing the buffer out to disk, in microseconds. A
-        nonzero delay can allow multiple transactions to be committed
-        with only one fsync() system call, if
-        system load is high enough that additional transactions become
-        ready to commit within the given interval. But the delay is
-        just wasted if no other transactions become ready to
-        commit. Therefore, the delay is only performed if at least
-        commit_siblings other transactions are
-        active at the instant that a server process has written its
-        commit record. The default is zero (no delay).
-       
-      
-     
-
-     
-      commit_siblings (integer)
-      
-       commit_siblings configuration parameter
-      
-      
-       
-        Minimum number of concurrent open transactions to require
-        before performing the commit_delay delay. A larger
-        value makes it more probable that at least one other
-        transaction will become ready to commit during the delay
-        interval. The default is five.
-       
-      
-     
-
-     
-     
-     
-     Checkpoints
-
-    
-     
-      checkpoint_segments (integer)
-      
-       checkpoint_segments configuration parameter
-      
-      
-       
-        Maximum distance between automatic WAL checkpoints, in log
-        file segments (each segment is normally 16 megabytes). The
-        default is three.  This option can only be set at server start
-        or in the postgresql.conf file.
-       
-      
-     
-
-     
-      checkpoint_timeout (integer)
-      
-       checkpoint_timeout configuration parameter
-      
-      
-       
-        Maximum time between automatic WAL checkpoints, in
-        seconds. The default is 300 seconds.  This option can only be
-        set at server start or in the postgresql.conf
-        file.
-       
-      
-     
-
-     
-      checkpoint_warning (integer)
-      
-       checkpoint_warning configuration parameter
-      
-      
-       
-        Write a message to the server log if checkpoints caused by
-        the filling of checkpoint segment files happen closer together
-        than this many seconds.  The default is 30 seconds.
-        Zero turns off the warning.
-       
-      
-     
-
-     
-     
-     
-     Archiving
-
-    
-     
-      archive_command (string)
-      
-       archive_command configuration parameter
-      
-      
-       
-        The shell command to execute to archive a completed segment of
-        the WAL file series. If this is an empty string (the default),
-        WAL archiving is disabled. Any %p in the string is
-        replaced by the absolute path of the file to archive, and any
-        %f is replaced by the file name only. Use
-        %% to embed an actual % character in the
-        command. For more information see 
-        linkend="backup-archiving-wal">. This option can only be set at
-        server start or in the postgresql.conf
-        file.
-       
-       
-        It is important for the command to return a zero exit status if
-        and only if it succeeds.  Examples:
-
-archive_command = 'cp "%p" /mnt/server/archivedir/"%f"'
-archive_command = 'copy "%p" /mnt/server/archivedir/"%f"'  # Windows
-
-       
-      
-     
-     
-     
-    
-   
-
-   
-    Query Planning
-
-    
-     Planner Method Configuration
-
-      
-       These configuration parameters provide a crude method of
-       influencing the query plans chosen by the query optimizer. If
-       the default plan chosen by the optimizer for a particular query
-       is not optimal, a temporary solution may be found by using one
-       of these configuration parameters to force the optimizer to
-       choose a different plan.  Turning one of these settings off
-       permanently is seldom a good idea, however.
-       Better ways to improve the quality of the
-       plans chosen by the optimizer include adjusting the 
-       linkend="runtime-config-query-constants"
-       endterm="runtime-config-query-constants-title">, running 
-       linkend="sql-analyze" endterm="sql-analyze-title"> more
-       frequently, increasing the value of the 
-       linkend="guc-default-statistics-target"> configuration parameter,
-       and increasing the amount of statistics collected for
-       specific columns using ALTER TABLE SET
-       STATISTICS.
-      
-
-     
-     
-      enable_bitmapscan (boolean)
-      
-       bitmap scan
-      
-      
-       enable_bitmapscan configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of bitmap-scan plan
-        types. The default is on.
-       
-      
-     
-
-     
-      enable_hashagg (boolean)
-      
-       enable_hashagg configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of hashed
-        aggregation plan types. The default is on.
-       
-      
-     
-
-     
-      enable_hashjoin (boolean)
-      
-       enable_hashjoin configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of hash-join plan
-        types. The default is on.
-       
-      
-     
-
-     
-      enable_indexscan (boolean)
-      
-       index scan
-      
-      
-       enable_indexscan configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of index-scan plan
-        types. The default is on.
-       
-      
-     
-
-     
-      enable_mergejoin (boolean)
-      
-       enable_mergejoin configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of merge-join plan
-        types. The default is on.
-       
-      
-     
-
-     
-      enable_nestloop (boolean)
-      
-       enable_nestloop configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of nested-loop join
-        plans. It's not possible to suppress nested-loop joins entirely,
-        but turning this variable off discourages the planner from using
-        one if there are other methods available. The default is
-        on.
-       
-      
-     
-
-     
-      enable_seqscan (boolean)
-      
-       sequential scan
-      
-      
-       enable_seqscan configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of sequential scan
-        plan types. It's not possible to suppress sequential scans
-        entirely, but turning this variable off discourages the planner
-        from using one if there are other methods available. The
-        default is on.
-       
-      
-     
-
-     
-      enable_sort (boolean)
-      
-       enable_sort configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of explicit sort
-        steps. It's not possible to suppress explicit sorts entirely,
-        but turning this variable off discourages the planner from
-        using one if there are other methods available. The default
-        is on.
-       
-      
-     
-
-     
-      enable_tidscan (boolean)
-      
-       enable_tidscan configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of TID
-        scan plan types. The default is on.
-       
-      
-     
-     
-     
-     
-     
-     
-      Planner Cost Constants
-     
-
-   
-    
-     Unfortunately, there is no well-defined method for determining
-     ideal values for the family of cost variables that
-     appear below. You are encouraged to experiment and share
-     your findings.
-    
-   
-
-     
-     
-     
-      effective_cache_size (floating point)
-      
-       effective_cache_size configuration parameter
-      
-      
-       
-        Sets the planner's assumption about the effective size of the
-        disk cache that is available to a single index scan.  This is
-        factored into estimates of the cost of using an index; a higher
-        value makes it more likely index scans will be used, a lower
-        value makes it more likely sequential scans will be used. When
-        setting this parameter you should consider both
-        PostgreSQL's shared buffers and the
-        portion of the kernel's disk cache that will be used for
-        PostgreSQL data files.  Also, take into
-        account the expected number of concurrent queries using different
-        indexes, since they will have to share the available space.
-        This parameter has no effect on the size of shared memory
-        allocated by PostgreSQL, nor does it reserve kernel disk cache;
-        it is used only for estimation purposes.
-        The value is measured in disk pages, which are
-        normally 8192 bytes each. The default is 1000.
-       
-      
-     
-
-     
-      random_page_cost (floating point)
-      
-       random_page_cost configuration parameter
-      
-      
-       
-        Sets the planner's estimate of the cost of a
-        nonsequentially fetched disk page. This is measured as a
-        multiple of the cost of a sequential page fetch. A higher
-        value makes it more likely a sequential scan will be used, a
-        lower value makes it more likely an index scan will be
-        used. The default is four.
-       
-      
-     
-
-     
-      cpu_tuple_cost (floating point)
-      
-       cpu_tuple_cost configuration parameter
-      
-      
-       
-        Sets the planner's estimate of the cost of processing
-        each row during a query. This is measured as a fraction of
-        the cost of a sequential page fetch. The default is 0.01.
-       
-      
-     
-
-     
-      cpu_index_tuple_cost (floating point)
-      
-       cpu_index_tuple_cost configuration parameter
-      
-      
-       
-        Sets the planner's estimate of the cost of processing
-        each index row during an index scan. This is measured as a
-        fraction of the cost of a sequential page fetch. The default
-        is 0.001.
-       
-      
-     
-    
-     
-      cpu_operator_cost (floating point)
-      
-       cpu_operator_cost configuration parameter
-      
-      
-       
-        Sets the planner's estimate of the cost of processing each
-        operator in a WHERE clause. This is measured as a fraction of
-        the cost of a sequential page fetch. The default is 0.0025.
-       
-      
-     
-
-     
-
-    
-     
-     Genetic Query Optimizer
-
-     
-
-     
-      
-       genetic query optimization
-      
-      
-       GEQO
-       genetic query optimization
-      
-      
-       geqo configuration parameter
-      
-      geqo (boolean)
-      
-       
-        Enables or disables genetic query optimization, which is an
-        algorithm that attempts to do query planning without
-        exhaustive searching. This is on by default. The
-        geqo_threshold variable provides a more
-        granular way to disable GEQO for certain classes of queries.
-       
-      
-     
-
-     
-      geqo_threshold (integer)
-      
-       geqo_threshold configuration parameter
-      
-      
-       
-        Use genetic query optimization to plan queries with at least
-        this many FROM items involved. (Note that an outer
-        JOIN construct counts as only one FROM
-        item.) The default is 12. For simpler queries it is usually best
-        to use the deterministic, exhaustive planner, but for queries with
-        many tables the deterministic planner takes too long.
-       
-      
-     
-
-     
-      geqo_effort
-      (integer)
-      
-       geqo_effort configuration parameter
-      
-      
-       
-        Controls the trade off between planning time and query plan
-        efficiency in GEQO. This variable must be an integer in the
-        range from 1 to 10. The default value is 5. Larger values
-        increase the time spent doing query planning, but also
-        increase the likelihood that an efficient query plan will be
-        chosen.
-       
-
-       
-        geqo_effort doesn't actually do anything
-        directly; it is only used to compute the default values for
-        the other variables that influence GEQO behavior (described
-        below). If you prefer, you can set the other parameters by
-        hand instead.
-       
-      
-     
-
-     
-      geqo_pool_size (integer)
-      
-       geqo_pool_size configuration parameter
-      
-      
-       
-        Controls the pool size used by GEQO. The pool size is the
-        number of individuals in the genetic population.  It must be
-        at least two, and useful values are typically 100 to 1000.  If
-        it is set to zero (the default setting) then a suitable
-        default is chosen based on geqo_effort and
-        the number of tables in the query.
-       
-      
-     
-
-     
-      geqo_generations (integer)
-      
-       geqo_generations configuration parameter
-      
-      
-       
-        Controls the number of generations used by GEQO.  Generations
-        specifies the number of iterations of the algorithm.  It must
-        be at least one, and useful values are in the same range as
-        the pool size.  If it is set to zero (the default setting)
-        then a suitable default is chosen based on
-        geqo_pool_size.
-       
-      
-     
-
-     
-      geqo_selection_bias (floating point)
-      
-       geqo_selection_bias configuration parameter
-      
-      
-       
-        Controls the selection bias used by GEQO. The selection bias
-        is the selective pressure within the population. Values can be
-        from 1.50 to 2.00; the latter is the default.
-       
-      
-     
-     
-     
-    
-     
-     Other Planner Options
-
-     
-
-     
-      default_statistics_target (integer)
-      
-       default_statistics_target configuration parameter
-      
-      
-       
-        Sets the default statistics target for table columns that have
-        not had a column-specific target set via ALTER TABLE
-        SET STATISTICS.  Larger values increase the time needed to
-        do ANALYZE, but may improve the quality of the
-        planner's estimates. The default is 10. For more information
-        on the use of statistics by the PostgreSQL
-        query planner, refer to .
-       
-      
-     
-
-     
-      constraint_exclusion (boolean)
-      
-       constraint exclusion
-      
-      
-       constraint_exclusion configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of table constraints to
-        limit table access.  The default is off.
-       
-
-       
-        When this parameter is on, the planner compares query
-        conditions with table CHECK constraints, and omits scanning tables
-        where the conditions contradict the constraints.  (Presently
-        this is done only for child tables of inheritance scans.)  For
-        example:
-
-
-CREATE TABLE parent(key integer, ...);
-CREATE TABLE child1000(check (key between 1000 and 1999)) INHERITS(parent);
-CREATE TABLE child2000(check (key between 2000 and 2999)) INHERITS(parent);
-...
-SELECT * FROM parent WHERE key = 2400;
-
-
-        With constraint exclusion enabled, this SELECT will not scan
-        child1000 at all.  This can improve performance when
-        inheritance is used to build partitioned tables.
-       
-
-       
-        Currently, constraint_exclusion defaults to
-        off, because it risks incorrect results if
-        query plans are cached --- if a table constraint is changed or dropped,
-        the previously generated plan might now be wrong, and there is no
-        built-in mechanism to force re-planning.  (This deficiency will
-        probably be addressed in a future
-        PostgreSQL release.)  Another reason
-        for keeping it off is that the constraint checks are relatively
-        expensive, and in many circumstances will yield no savings.
-        It is recommended to turn this on only if you are actually using
-        partitioned tables designed to take advantage of the feature.
-       
-      
-     
-
-     
-      from_collapse_limit (integer)
-      
-       from_collapse_limit configuration parameter
-      
-      
-       
-        The planner will merge sub-queries into upper queries if the
-        resulting FROM list would have no more than
-        this many items.  Smaller values reduce planning time but may
-        yield inferior query plans.  The default is 8.  It is usually
-        wise to keep this less than .
-       
-      
-     
-
-     
-      join_collapse_limit (integer)
-      
-       join_collapse_limit configuration parameter
-      
-      
-       
-        The planner will rewrite explicit inner JOIN
-        constructs into lists of FROM items whenever a
-        list of no more than this many items in total would
-        result. Prior to PostgreSQL 7.4, joins
-        specified via the JOIN construct would
-        never be reordered by the query planner. The query planner has
-        subsequently been improved so that inner joins written in this
-        form can be reordered; this configuration parameter controls
-        the extent to which this reordering is performed.
-        
-         
-          At present, the order of outer joins specified via the
-          JOIN construct is never adjusted by the query
-          planner; therefore, join_collapse_limit has no
-          effect on this behavior. The planner may be improved to
-          reorder some classes of outer joins in a future release of
-          PostgreSQL.
-         
-        
-       
-
-       
-        By default, this variable is set the same as
-        from_collapse_limit, which is appropriate
-        for most uses. Setting it to 1 prevents any reordering of
-        inner JOINs. Thus, the explicit join order
-        specified in the query will be the actual order in which the
-        relations are joined. The query planner does not always choose
-        the optimal join order; advanced users may elect to
-        temporarily set this variable to 1, and then specify the join
-        order they desire explicitly. Another consequence of setting
-        this variable to 1 is that the query planner will behave more
-        like the PostgreSQL 7.3 query
-        planner, which some users might find useful for backward
-        compatibility reasons.
-       
-
-       
-        Setting this variable to a value between 1 and
-        from_collapse_limit might be useful to
-        trade off planning time against the quality of the chosen plan
-        (higher values produce better plans).
-       
-      
-     
-     
-     
-    
-   
-
-   
-    Error Reporting and Logging
-
-    
-     server log
-    
-
-    
-     Where to log
-
-     
-      where to log
-     
-
-     
-
-     
-      log_destination (string)
-      
-       log_destination configuration parameter
-      
-      
-       
-        PostgreSQL supports several methods
-         for logging server messages, including
-         stderr and
-         syslog. On Windows, 
-         eventlog is also supported. Set this
-         option to a list of desired log destinations separated by
-         commas. The default is to log to stderr 
-         only.
-         This option can only be set at server start or in the
-         postgresql.conf configuration file.
-       
-      
-     
-
-     
-      redirect_stderr (boolean)
-      
-       redirect_stderr configuration parameter
-      
-      
-       
-         This option allows messages sent to stderr to be
-         captured and redirected into log files.
-         This option, in combination with logging to stderr,
-         is often more useful than
-         logging to syslog, since some types of messages
-         may not appear in syslog output (a common example
-         is dynamic-linker failure messages).
-         This option can only be set at server start.
-       
-      
-     
-
-     
-      log_directory (string)
-      
-       log_directory configuration parameter
-      
-      
-       
-        When redirect_stderr is enabled, this option
-        determines the directory in which log files will be created.
-        It may be specified as an absolute path, or relative to the
-        cluster data directory.
-        This option can only be set at server start or in the
-        postgresql.conf configuration file.
-       
-      
-     
-
-     
-      log_filename (string)
-      
-       log_filename configuration parameter
-      
-      
-       
-        When redirect_stderr is enabled, this option
-        sets the file names of the created log files.  The value
-        is treated as a strftime pattern,
-        so %-escapes
-        can be used to specify time-varying file names.
-        If no %-escapes are present,
-        PostgreSQL will
-        append the epoch of the new log file's open time.  For example,
-        if log_filename were server_log, then the
-        chosen file name would be server_log.1093827753
-        for a log starting at Sun Aug 29 19:02:33 2004 MST.
-        This option can only be set at server start or in the
-        postgresql.conf configuration file.
-       
-      
-     
-
-     
-      log_rotation_age (integer)
-      
-       log_rotation_age configuration parameter
-      
-      
-       
-        When redirect_stderr is enabled, this option
-        determines the maximum lifetime of an individual log file.
-        After this many minutes have elapsed, a new log file will
-        be created.  Set to zero to disable time-based creation of
-        new log files.
-        This option can only be set at server start or in the
-        postgresql.conf configuration file.
-       
-      
-     
-
-     
-      log_rotation_size (integer)
-      
-       log_rotation_size configuration parameter
-      
-      
-       
-        When redirect_stderr is enabled, this option
-        determines the maximum size of an individual log file.
-        After this many kilobytes have been emitted into a log file,
-        a new log file will be created.  Set to zero to disable size-based
-        creation of new log files.
-        This option can only be set at server start or in the
-        postgresql.conf configuration file.
-       
-      
-     
-
-     
-      log_truncate_on_rotation (boolean)
-      
-       log_truncate_on_rotation configuration parameter
-      
-      
-       
-        When redirect_stderr is enabled, this option will cause
-        PostgreSQL to truncate (overwrite),
-        rather than append to, any existing log file of the same name.
-        However, truncation will occur only when a new file is being opened
-        due to time-based rotation, not during server startup or size-based
-        rotation.  When off, pre-existing files will be appended to in
-        all cases.  For example, using this option in combination with
-        a log_filename like postgresql-%H.log
-        would result in generating twenty-four hourly log files and then
-        cyclically overwriting them.
-        This option can only be set at server start or in the
-        postgresql.conf configuration file.
-       
-       
-        Example:  To keep 7 days of logs, one log file per day named
-        server_log.Mon, server_log.Tue, 
-        etc, and automatically overwrite last week's log with this week's log,
-        set log_filename to server_log.%a, 
-        log_truncate_on_rotation to on, and 
-        log_rotation_age to 1440.
-       
-       
-        Example: To keep 24 hours of logs, one log file per hour, but 
-        also rotate sooner if the log file size exceeds 1GB, set 
-        log_filename to server_log.%H%M, 
-        log_truncate_on_rotation to on, 
-        log_rotation_age to 60, and 
-        log_rotation_size to 1000000.
-        Including %M in log_filename allows
-        any size-driven rotations that may occur to select a filename
-        different from the hour's initial filename.
-       
-      
-     
-
-     
-      syslog_facility (string)
-      
-       syslog_facility configuration parameter
-      
-      
-       
-        When logging to syslog is enabled, this option
-        determines the syslog
-        facility to be used.  You may choose
-        from LOCAL0, LOCAL1,
-        LOCAL2, LOCAL3, LOCAL4,
-        LOCAL5, LOCAL6, LOCAL7;
-        the default is LOCAL0. See also the
-        documentation of your system's
-        syslog daemon.
-        This option can only be set at server start.
-       
-      
-     
-     
-     
-      syslog_ident (string)
-      
-       syslog_identity configuration parameter
-      
-       
-        
-         When logging to syslog is enabled, this option
-         determines the program name used to identify
-         PostgreSQL messages in
-         syslog logs. The default is
-         postgres.
-          This option can only be set at server start.
-        
-       
-      
-      
-      
-    
-     
-     When To Log
-
-     
-
-     
-      client_min_messages (string)
-      
-       client_min_messages configuration parameter
-      
-      
-       
-        Controls which message levels are sent to the client.
-        Valid values are DEBUG5,
-        DEBUG4, DEBUG3, DEBUG2,
-        DEBUG1, LOG, NOTICE,
-        WARNING, and ERROR.  Each level
-        includes all the levels that follow it.  The later the level,
-        the fewer messages are sent.  The default is
-        NOTICE.  Note that LOG has a different
-        rank here than in log_min_messages.
-       
-      
-     
-
-     
-      log_min_messages (string)
-      
-       log_min_messages configuration parameter
-      
-      
-       
-        Controls which message levels are written to the server log.
-        Valid values are DEBUG5, DEBUG4,
-        DEBUG3, DEBUG2, DEBUG1,
-        INFO, NOTICE, WARNING,
-        ERROR, LOG, FATAL, and
-        PANIC.  Each level includes all the levels that
-        follow it.  The later the level, the fewer messages are sent
-        to the log.  The default is NOTICE.  Note that
-        LOG has a different rank here than in
-        client_min_messages.
-        Only superusers can change this setting.
-       
-      
-     
-
-     
-      log_error_verbosity (string)
-      
-       log_error_verbosity configuration parameter
-      
-      
-       
-        Controls the amount of detail written in the server log for each
-        message that is logged.  Valid values are TERSE,
-        DEFAULT, and VERBOSE, each adding more
-        fields to displayed messages.
-        Only superusers can change this setting.
-       
-      
-     
-
-     
-      log_min_error_statement (string)
-      
-       log_min_error_statement configuration parameter
-      
-      
-       
-        Controls whether or not the SQL statement that causes an error
-        condition will also be recorded in the server log. All SQL
-        statements that cause an error of the specified level or
-        higher are logged.  The default is
-        PANIC (effectively turning this feature
-        off for normal use). Valid values are DEBUG5,
-        DEBUG4, DEBUG3,
-        DEBUG2, DEBUG1,
-        INFO, NOTICE,
-        WARNING, ERROR,
-        FATAL, and PANIC.  For
-        example, if you set this to ERROR then all
-        SQL statements causing errors, fatal errors, or panics will be
-        logged. Enabling this option can be helpful in tracking down
-        the source of any errors that appear in the server log.
-        Only superusers can change this setting.
-       
-      
-     
-     
-     
-      log_min_duration_statement (integer)
-      
-       log_min_duration_statement configuration parameter
-      
-       
-        
-         Logs the statement and its duration on a single log line if its
-         duration is greater than or equal to the specified number of
-         milliseconds. Setting this to zero will print all statements
-         and their durations. Minus-one (the default) disables the
-         feature. For example, if you set it to 250
-         then all SQL statements that run 250ms or longer will be
-         logged. Enabling this option can be useful in tracking down
-         unoptimized queries in your applications. This setting is
-         independent of log_statement and
-         log_duration. Only superusers can change
-         this setting.
-        
-       
-      
-
-     
-      silent_mode (boolean)
-      
-       silent_mode configuration parameter
-      
-      
-       
-        Runs the server silently. If this option is set, the server
-        will automatically run in background and any controlling
-        terminals are disassociated (same effect as
-        postmaster's -S option).
-        The server's standard output and standard error are redirected
-        to /dev/null, so any messages sent to them will be lost.
-        Unless syslog logging is selected or
-        redirect_stderr is enabled, using this option
-        is discouraged because it makes it impossible to see error messages.
-       
-      
-     
-
-     
-
-       
-        Here is a list of the various message severity levels used in
-        these settings:
-        
-         
-          DEBUG[1-5]
-          
-           
-            Provides information for use by developers.
-           
-          
-         
-
-         
-          INFO
-          
-           
-            Provides information implicitly requested by the user,
-            e.g., during VACUUM VERBOSE.
-           
-          
-         
-
-         
-          NOTICE
-          
-           
-            Provides information that may be helpful to users, e.g.,
-            truncation of long identifiers and the creation of indexes as part
-            of primary keys.
-           
-          
-         
-
-         
-          WARNING
-          
-           
-            Provides warnings to the user, e.g., COMMIT
-            outside a transaction block.
-           
-          
-         
-
-         
-          ERROR
-          
-           
-            Reports an error that caused the current command to abort.
-           
-          
-         
-
-         
-          LOG
-          
-           
-            Reports information of interest to administrators, e.g.,
-            checkpoint activity.
-           
-          
-         
-
-         
-          FATAL
-          
-           
-            Reports an error that caused the current session to abort.
-           
-          
-         
-
-         
-          PANIC
-          
-           
-            Reports an error that caused all sessions to abort.
-           
-          
-         
-        
-       
-
-    
-     
-     What To Log
-
-     
-
-     
-      debug_print_parse (boolean)
-      debug_print_rewritten (boolean)
-      debug_print_plan (boolean)
-      debug_pretty_print (boolean)
-      
-       debug_print_parse configuration parameter
-      
-      
-       debug_print_rewritten configuration parameter
-      
-      
-       debug_print_plan configuration parameter
-      
-      
-       debug_pretty_print configuration parameter
-      
-      
-       
-        These options enable various debugging output to be emitted.
-        For each executed query, they print
-        the resulting parse tree, the query rewriter output, or the
-        execution plan.  debug_pretty_print indents
-        these displays to produce a more readable but much longer
-        output format.  client_min_messages or
-        log_min_messages must be
-        DEBUG1 or lower to actually send this output
-        to the client or the server log, respectively.
-        These options are off by default.
-       
-      
-     
-
-     
-      log_connections (boolean)
-      
-       log_connections configuration parameter
-      
-      
-       
-        This outputs a line to the server log detailing each successful
-        connection. This is off by default, although it is probably very
-        useful. This option can only be set at server start or in the
-        postgresql.conf configuration file.
-       
-      
-     
-
-     
-      log_disconnections (boolean)
-      
-       log_disconnections configuration parameter
-      
-      
-       
-        This outputs a line in the server log similar to
-        log_connections but at session termination,
-        and includes the duration of the session.  This is off by
-        default. This option can only be set at server start or in the
-        postgresql.conf configuration file.
-       
-      
-     
-
-
-     
-      log_duration (boolean)
-      
-       log_duration configuration parameter
-      
-      
-       
-        Causes the duration of every completed statement which satisfies
-        log_statement to be logged.  When using this option, 
-        if you are not using syslog, it is recommended 
-        that you log the PID or session ID using log_line_prefix 
-        so that you can link the statement to the 
-        duration using the process ID or session ID. The default is
-        off. Only superusers can change this setting.
-       
-      
-     
-     
-     
-      log_line_prefix (string)
-      
-       log_line_prefix configuration parameter
-      
-      
-       
-         This is a printf-style string that is output at the
-         beginning of each log line. The default is an empty string.
-         Each recognized escape is replaced as outlined 
-         below - anything else that looks like an escape is ignored. Other
-         characters are copied straight to the log line. Some escapes are
-         only recognised by session processes, and do not apply to
-         background processes such as the postmaster. Syslog
-         produces its own 
-         time stamp and process ID information, so you probably do not want to
-         use those escapes if you are using syslog.
-         This option can only be set at server start or in the
-         postgresql.conf configuration file.
-
-         
-          
-           
-            
-             Escape
-             Effect
-             Session only
-             
-            
-           
-            
-             %u
-             User name
-             yes
-            
-            
-             %d
-             Database name
-             yes
-            
-            
-             %r
-             Remote host name or IP address, and remote port
-             yes
-            
-            
-             %h
-             Remote Hostname or IP address
-             yes
-            
-            
-             %p
-             Process ID
-             no
-            
-            
-             %t
-             Time stamp (no milliseconds)
-             no
-            
-            
-             %m
-             Time stamp with milliseconds
-             no
-            
-            
-             %i
-             Command tag: This is the command that generated the log line.
-             yes
-            
-            
-             %c
-             Session ID: A unique identifier for each session.
-             It is 2 4-byte hexadecimal numbers (without leading zeros) 
-             separated by a dot. The numbers
-             are the session start time and the process ID, so this can also
-             be used as a space saving way of printing these items.
-             yes
-            
-            
-             %l
-             Number of the log line for each process, starting at 1
-             no
-            
-            
-             %s
-             Session start time stamp
-             yes
-            
-            
-             %x
-             Transaction ID
-             yes
-            
-            
-             %q
-             Does not produce any output, but tells non-session
-             processes to stop at this point in the string. Ignored by
-             session processes.
-             no
-            
-            
-             %%
-             Literal %
-             no
-            
-           
-          
-         
-       
-      
-     
-
-     
-      log_statement (string)
-      
-       log_statement configuration parameter
-      
-      
-       
-        Controls which SQL statements are logged. Valid values are
-        none, ddl, mod, and
-        all. ddl logs all data definition
-        commands like CREATE, ALTER, and
-        DROP commands. mod logs all
-        ddl statements, plus INSERT,
-        UPDATE, DELETE, TRUNCATE,
-        and COPY FROM. PREPARE and
-        EXPLAIN ANALYZE statements are also logged if their
-        contained command is of an appropriate type.
-       
-       
-        The default is none. Only superusers can change this
-        setting.
-       
-
-       
-        
-         The EXECUTE statement is not considered a
-         ddl or mod statement.  When it is logged, 
-         only the name of the prepared statement is reported, not the
-         actual prepared statement.
-        
-
-        
-         When a function is defined in the
-         PL/pgSQLserver-side language, any queries
-         executed by the function will only be logged the first time that the
-         function is invoked in a particular session. This is because
-         PL/pgSQL keeps a cache of the
-         query plans produced for the SQL statements in the function.
-        
-       
-      
-     
-
-     
-      log_hostname (boolean)
-      
-       log_hostname configuration parameter
-      
-      
-       
-        By default, connection log messages only show the IP address of the
-        connecting host. Turning on this option causes logging of the
-        host name as well.  Note that depending on your host name resolution
-        setup this might impose a non-negligible performance penalty. This
-        option can only be set at server start or in the
-        postgresql.conf file.
-       
-      
-     
-
-     
-    
-   
-
-   
-    Runtime Statistics
-
-    
-     Statistics Monitoring
-     
-
-     
-      log_statement_stats (boolean)
-      log_parser_stats (boolean)
-      log_planner_stats (boolean)
-      log_executor_stats (boolean)
-      
-       log_statement_stats configuration parameter
-      
-      
-       log_parser_stats configuration parameter
-      
-      
-       log_planner_stats configuration parameter
-      
-      
-       log_executor_stats configuration parameter
-      
-      
-       
-        For each query, write performance statistics of the respective
-        module to the server log. This is a crude profiling
-        instrument.  log_statement_stats reports total
-        statement statistics, while the others report per-module statistics.
-        log_statement_stats cannot be enabled together with
-        any of the per-module options.  All of these options are disabled by
-        default.   Only superusers can change these settings.
-       
-      
-     
-
-     
-
-    
-    
-     Query and Index Statistics Collector
-     
-
-     
-      stats_start_collector (boolean)
-      
-       stats_start_collector configuration parameter
-      
-      
-       
-        Controls whether the server should start the
-        statistics-collection subprocess.  This is on by default, but
-        may be turned off if you know you have no interest in
-        collecting statistics.  This option can only be set at server
-        start.
-       
-      
-     
-
-     
-      stats_command_string (boolean)
-      
-       stats_command_string configuration parameter
-      
-      
-       
-        Enables the collection of statistics on the currently
-        executing command of each session, along with the time at
-        which that command began execution. This option is off by
-        default. Note that even when enabled, this information is not
-        visible to all users, only to superusers and the user owning
-        the session being reported on; so it should not represent a
-        security risk. This data can be accessed via the
-        pg_stat_activity system view; refer
-        to  for more information.
-       
-      
-     
-
-     
-      stats_block_level (boolean)
-      
-       stats_block_level configuration parameter
-      
-      
-       
-        Enables the collection of block-level statistics on database
-        activity. This option is disabled by default. If this option
-        is enabled, the data that is produced can be accessed via the
-        pg_stat and
-        pg_statio family of system views;
-        refer to  for more information.
-       
-      
-     
-
-     
-      stats_row_level (boolean)
-      
-       stats_row_level configuration parameter
-      
-      
-       
-        Enables the collection of row-level statistics on database
-        activity. This option is disabled by default. If this option
-        is enabled, the data that is produced can be accessed via the
-        pg_stat and
-        pg_statio family of system views;
-        refer to  for more information.
-       
-      
-     
-
-     
-      stats_reset_on_server_start (boolean)
-      
-       stats_reset_on_server_start configuration parameter
-      
-      
-       
-        If on, collected statistics are zeroed out whenever the server
-        is restarted. If off, statistics are accumulated across server
-        restarts. The default is off. This option can only 
-        be set at server start.
-       
-      
-     
-
-     
-    
-   
-
-   
-    Automatic Vacuuming
-
-     
-      Beginning in PostgreSQL 8.1, there is an optional server
-      process called the autovacuum daemon, whose purpose is
-      to automate the issuance of periodic VACUUM and
-      ANALYZE commands.  When enabled, the autovacuum daemon
-      runs periodically and checks for tables that have had a large number
-      of updated or deleted tuples.  This check uses the row-level statistics
-      collection facility; therefore, the autovacuum daemon cannot be used
-      unless  and
-       are set TRUE.  Also, it's
-      important to allow a slot for the autovacuum process when choosing
-      the value of .
-     
-
-    
-
-     
-      autovacuum (boolean)
-      
-       autovacuum configuration parameter
-      
-      
-       
-        Controls whether the server should start the
-        autovacuum subprocess.  This is off by default.
-        This option can only be set at server start or in the
-        postgresql.conf file.
-       
-      
-     
-
-     
-      autovacuum_naptime (integer)
-      
-       autovacuum_naptime configuration parameter
-      
-      
-       
-        Specifies the delay between activity rounds for the autovacuum
-        subprocess.  In each round the subprocess examines one database
-        and issues VACUUM and ANALYZE commands
-        as needed for tables in that database.  The delay is measured
-        in seconds, and the default is 60.
-        This option can only be set at server start or in the
-        postgresql.conf file.
-       
-      
-     
-
-     
-      autovacuum_vacuum_threshold (integer)
-      
-       autovacuum_vacuum_threshold configuration parameter
-      
-      
-       
-        Specifies the minimum number of updated or deleted tuples needed
-        to trigger a VACUUM in any one table.
-        The default is 1000.
-        This option can only be set at server start or in the
-        postgresql.conf file.
-       
-      
-     
-
-     
-      autovacuum_analyze_threshold (integer)
-      
-       autovacuum_analyze_threshold configuration parameter
-      
-      
-       
-        Specifies the minimum number of inserted, updated or deleted tuples
-        needed to trigger an ANALYZE in any one table.
-        The default is 500.
-        This option can only be set at server start or in the
-        postgresql.conf file.
-       
-      
-     
-
-     
-      autovacuum_vacuum_scale_factor (floating point)
-      
-       autovacuum_vacuum_scale_factor configuration parameter
-      
-      
-       
-        Specifies a fraction of the table size to add to
-        autovacuum_vacuum_threshold
-        when deciding whether to trigger a VACUUM.
-        The default is 0.4.
-        This option can only be set at server start or in the
-        postgresql.conf file.
-       
-      
-     
-
-     
-      autovacuum_analyze_scale_factor (floating point)
-      
-       autovacuum_analyze_scale_factor configuration parameter
-      
-      
-       
-        Specifies a fraction of the table size to add to
-        autovacuum_analyze_threshold
-        when deciding whether to trigger an ANALYZE.
-        The default is 0.2.
-        This option can only be set at server start or in the
-        postgresql.conf file.
-       
-      
-     
-
-     
-      autovacuum_vacuum_cost_delay (integer)
-      
-       autovacuum_vacuum_cost_delay configuration parameter
-      
-      
-       
-        Specifies the cost delay value that will be used in automatic
-        VACUUM operations.  If -1 is specified (which is the
-        default), the regular
-         value will be used.
-        This setting can be overridden for individual tables by entries in
-        pg_autovacuum.
-       
-      
-     
-
-     
-      autovacuum_vacuum_cost_limit (integer)
-      
-       autovacuum_vacuum_cost_limit configuration parameter
-      
-      
-       
-        Specifies the cost limit value that will be used in automatic
-        VACUUM operations.  If -1 is specified (which is the
-        default), the regular
-         value will be used.
-        This setting can be overridden for individual tables by entries in
-        pg_autovacuum.
-       
-      
-     
-
-    
-   
-
-   
-    Client Connection Defaults
-
-    
-     Statement Behavior
-     
-
-     
-      search_path (string)
-      
-       search_path configuration parameter
-      
-      pathfor schemas
-      
-       
-        This variable specifies the order in which schemas are searched
-        when an object (table, data type, function, etc.) is referenced by a
-        simple name with no schema component.  When there are objects of
-        identical names in different schemas, the one found first
-        in the search path is used.  An object that is not in any of the
-        schemas in the search path can only be referenced by specifying
-        its containing schema with a qualified (dotted) name.
-       
-
-       
-        The value for search_path has to be a comma-separated
-        list of schema names.  If one of the list items is
-        the special value $user, then the schema
-        having the name returned by SESSION_USER is substituted, if there
-        is such a schema.  (If not, $user is ignored.)
-       
-
-       
-        The system catalog schema, pg_catalog, is always
-        searched, whether it is mentioned in the path or not.  If it is
-        mentioned in the path then it will be searched in the specified
-        order.  If pg_catalog is not in the path then it will
-        be searched before searching any of the path items.
-        It should also be noted that the temporary-table schema,
-        pg_temp_nnn, is implicitly searched before any of
-        these.
-       
-
-       
-        When objects are created without specifying a particular target
-        schema, they will be placed in the first schema listed
-        in the search path.  An error is reported if the search path is
-        empty.
-       
-
-       
-        The default value for this parameter is
-        '$user, public' (where the second part will be
-        ignored if there is no schema named public).
-        This supports shared use of a database (where no users
-        have private schemas, and all share use of public),
-        private per-user schemas, and combinations of these.  Other
-        effects can be obtained by altering the default search path
-        setting, either globally or per-user.
-       
-
-       
-        The current effective value of the search path can be examined
-        via the SQL function
-        current_schemas().  This is not quite the same as
-        examining the value of search_path, since
-        current_schemas() shows how the requests
-        appearing in search_path were resolved.
-       
-
-       
-        For more information on schema handling, see .
-       
-      
-     
-
-     
-      default_tablespace (string)
-      
-       default_tablespace configuration parameter
-      
-      tablespacedefault
-      
-       
-        This variable specifies the default tablespace in which to create
-        objects (tables and indexes) when a CREATE command does
-        not explicitly specify a tablespace.
-       
-
-       
-        The value is either the name of a tablespace, or an empty string
-        to specify using the default tablespace of the current database.
-        If the value does not match the name of any existing tablespace,
-        PostgreSQL will automatically use the default
-        tablespace of the current database.
-       
-
-       
-        For more information on tablespaces,
-        see .
-       
-      
-     
-
-     
-      check_function_bodies (boolean)
-      
-       check_function_bodies configuration parameter
-      
-      
-       
-        This parameter is normally on. When set to off, it
-        disables validation of the function body string during 
-        linkend="sql-createfunction"
-        endterm="sql-createfunction-title">. Disabling validation is
-        occasionally useful to avoid problems such as forward references
-        when restoring function definitions from a dump.
-       
-      
-     
-
-     
-      
-       transaction isolation level
-      
-      
-       default_transaction_isolation configuration parameter
-      
-      default_transaction_isolation (string)
-      
-       
-        Each SQL transaction has an isolation level, which can be
-        either read uncommitted, read
-        committed, repeatable read, or
-        serializable.  This parameter controls the
-        default isolation level of each new transaction. The default
-        is read committed.
-       
-
-       
-        Consult  and 
-        linkend="sql-set-transaction"
-        endterm="sql-set-transaction-title"> for more information.
-       
-      
-     
-
-     
-      
-       read-only transaction
-      
-      
-       default_transaction_read_only configuration parameter
-      
-
-      default_transaction_read_only (boolean)
-      
-       
-        A read-only SQL transaction cannot alter non-temporary tables.
-        This parameter controls the default read-only status of each new
-        transaction. The default is off (read/write).
-       
-
-       
-        Consult 
-        endterm="sql-set-transaction-title"> for more information.
-       
-      
-     
-     
-     
-      statement_timeout (integer)
-      
-       statement_timeout configuration parameter
-      
-      
-       
-        Abort any statement that takes over the specified number of
-        milliseconds.  A value of zero (the default) turns off the limitation.
-       
-      
-     
-     
-     
-    
-     
-     Locale and Formatting
-
-     
-
-     
-      DateStyle (string)
-      
-       DateStyle configuration parameter
-      
-      
-       
-        Sets the display format for date and time values, as well as the
-        rules for interpreting ambiguous date input values. For
-        historical reasons, this variable contains two independent
-        components: the output format specification (ISO,
-        Postgres, SQL, or German)
-        and the input/output specification for year/month/day ordering
-        (DMY, MDY, or YMD). These
-        can be set separately or together. The keywords Euro
-        and European are synonyms for DMY; the
-        keywords US, NonEuro, and
-        NonEuropean are synonyms for MDY. See
-         for more information. The
-        default is ISO, MDY.
-       
-      
-     
-
-     
-      timezone (string)
-      
-       timezone configuration parameter
-      
-      time zone
-      
-       
-        Sets the time zone for displaying and interpreting time
-        stamps.  The default is 'unknown', which means to use whatever 
-        the system environment specifies as the time zone.  See 
-        linkend="datatype-datetime"> for more information.
-       
-      
-     
-
-     
-      australian_timezones (boolean)
-      
-       australian_timezones configuration parameter
-      
-      time zoneAustralian
-      
-       
-        If set to on, ACST,
-        CST, EST, and
-        SAT are interpreted as Australian time
-        zones rather than as North/South American time zones and
-        Saturday. The default is off.
-       
-      
-     
-
-     
-      
-       significant digits
-      
-      
-       floating-point
-       display
-      
-      
-       extra_float_digits configuration parameter
-      
-
-      extra_float_digits (integer)
-      
-       
-        This parameter adjusts the number of digits displayed for
-        floating-point values, including float4, float8,
-        and geometric data types.  The parameter value is added to the
-        standard number of digits (FLT_DIG or DBL_DIG
-        as appropriate).  The value can be set as high as 2, to include
-        partially-significant digits; this is especially useful for dumping
-        float data that needs to be restored exactly.  Or it can be set
-        negative to suppress unwanted digits.
-       
-      
-     
-
-     
-      client_encoding (string)
-      
-       client_encoding configuration parameter
-      
-      character set
-      
-       
-        Sets the client-side encoding (character set).
-        The default is to use the database encoding.
-       
-      
-     
-
-     
-      lc_messages (string)
-      
-       lc_messages configuration parameter
-      
-      
-       
-        Sets the language in which messages are displayed.  Acceptable
-        values are system-dependent; see  for
-        more information.  If this variable is set to the empty string
-        (which is the default) then the value is inherited from the
-        execution environment of the server in a system-dependent way.
-       
-
-       
-        On some systems, this locale category does not exist.  Setting
-        this variable will still work, but there will be no effect.
-        Also, there is a chance that no translated messages for the
-        desired language exist.  In that case you will continue to see
-        the English messages.
-       
-      
-     
-
-     
-      lc_monetary (string)
-      
-       lc_monetary configuration parameter
-      
-      
-       
-        Sets the locale to use for formatting monetary amounts, for
-        example with the to_char family of
-        functions.  Acceptable values are system-dependent; see 
-        linkend="locale"> for more information.  If this variable is
-        set to the empty string (which is the default) then the value
-        is inherited from the execution environment of the server in a
-        system-dependent way.
-       
-      
-     
-
-     
-      lc_numeric (string)
-      
-       lc_numeric configuration parameter
-      
-      
-       
-        Sets the locale to use for formatting numbers, for example
-        with the to_char family of
-        functions. Acceptable values are system-dependent; see 
-        linkend="locale"> for more information.  If this variable is
-        set to the empty string (which is the default) then the value
-        is inherited from the execution environment of the server in a
-        system-dependent way.
-       
-      
-     
-
-     
-      lc_time (string)
-      
-       lc_time configuration parameter
-      
-      
-       
-        Sets the locale to use for formatting date and time values.
-        (Currently, this setting does nothing, but it may in the
-        future.)  Acceptable values are system-dependent; see 
-        linkend="locale"> for more information.  If this variable is
-        set to the empty string (which is the default) then the value
-        is inherited from the execution environment of the server in a
-        system-dependent way.
-       
-      
-     
-
-     
-
-    
-     
-     Other Defaults
-
-     
-
-     
-      explain_pretty_print (boolean)
-      
-       explain_pretty_print configuration parameter
-      
-      
-       
-        Determines whether EXPLAIN VERBOSE uses the
-        indented or non-indented format for displaying detailed
-        query-tree dumps. The default is on.
-       
-      
-     
-
-     
-      dynamic_library_path (string)
-      
-       dynamic_library_path configuration parameter
-      
-      dynamic loading
-      
-       
-        If a dynamically loadable module needs to be opened and the
-        file name specified in the CREATE FUNCTION or
-        LOAD command
-        does not have a directory component (i.e. the
-        name does not contain a slash), the system will search this
-        path for the required file.
-       
-
-       
-        The value for dynamic_library_path has to be a
-        list of absolute directory paths separated by colons (or semi-colons
-        on Windows).  If a list element starts
-        with the special string $libdir, the
-        compiled-in PostgreSQL package
-        library directory is substituted for $libdir. This
-        is where the modules provided by the standard
-        PostgreSQL distribution are installed.
-        (Use pg_config --pkglibdir to find out the name of
-        this directory.) For example:
-
-dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
-
-        or, in a Windows environment:
-
-dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
-
-       
-
-       
-        The default value for this parameter is
-        '$libdir'. If the value is set to an empty
-        string, the automatic path search is turned off.
-       
-
-       
-        This parameter can be changed at run time by superusers, but a
-        setting done that way will only persist until the end of the
-        client connection, so this method should be reserved for
-        development purposes. The recommended way to set this parameter
-        is in the postgresql.conf configuration
-        file.
-       
-      
-     
-
-     
-    
-   
-
-   
-    Lock Management
-
-     
-
-     
-      
-       deadlock
-       timeout during
-      
-      
-       timeout
-       deadlock
-      
-      
-       deadlock_timeout configuration parameter
-      
-
-      deadlock_timeout (integer)
-      
-       
-        This is the amount of time, in milliseconds, to wait on a lock
-        before checking to see if there is a deadlock condition. The
-        check for deadlock is relatively slow, so the server doesn't run
-        it every time it waits for a lock. We (optimistically?) assume
-        that deadlocks are not common in production applications and
-        just wait on the lock for a while before starting the check for a
-        deadlock. Increasing this value reduces the amount of time
-        wasted in needless deadlock checks, but slows down reporting of
-        real deadlock errors. The default is 1000 (i.e., one second),
-        which is probably about the smallest value you would want in
-        practice. On a heavily loaded server you might want to raise it.
-        Ideally the setting should exceed your typical transaction time,
-        so as to improve the odds that a lock will be released before
-        the waiter decides to check for deadlock.
-       
-      
-     
-
-     
-      max_locks_per_transaction (integer)
-      
-       max_locks_per_transaction configuration parameter
-      
-      
-       
-        The shared lock table is created with room to describe locks on
-        max_locks_per_transaction *
-        ( +
-        ) objects;
-        hence, no more than this many distinct objects can
-        be locked at any one time. (Thus, this parameter's name may be
-        confusing: it is not a hard limit on the number of locks taken
-        by any one transaction, but rather a maximum average value.)
-        The default, 64, has historically
-        proven sufficient, but you might need to raise this value if you
-        have clients that touch many different tables in a single
-        transaction. This option can only be set at server start.
-       
-
-       
-        Increasing this parameter may cause PostgreSQL
-        to request more System V shared
-        memory than your operating system's default configuration
-        allows. See  for information on how to
-        adjust those parameters, if necessary.
-       
-      
-     
-
-     
-   
-
-   
-    Version and Platform Compatibility
-
-    
-     Previous PostgreSQL Versions
-     
-
-     
-      add_missing_from (boolean)
-      FROMmissing
-      
-       add_missing_from configuration parameter
-      
-      
-       
-        When on, tables that are referenced by a query will be
-        automatically added to the FROM clause if not
-        already present. This behavior does not comply with the SQL
-        standard and many people dislike it because it can mask mistakes
-        (such as referencing a table where you should have referenced
-        its alias). The default is off. This variable can be
-        enabled for compatibility with releases of
-        PostgreSQL prior to 8.1, where this behavior was
-        allowed by default.
-       
-
-       
-        Note that even when this variable is enabled, a warning
-        message will be emitted for each implicit FROM
-        entry referenced by a query. Users are encouraged to update
-        their applications to not rely on this behavior, by adding all
-        tables referenced by a query to the query's FROM
-        clause (or its USING clause in the case of
-        DELETE).
-       
-      
-     
-
-     
-      regex_flavor (string)
-      regular expressions
-      
-       regex_flavor configuration parameter
-      
-      
-       
-        The regular expression flavor can be set to
-        advanced, extended, or basic.
-        The default is advanced.  The extended
-        setting may be useful for exact backwards compatibility with
-        pre-7.4 releases of PostgreSQL.  See
-         for details.
-       
-      
-     
-
-     
-      sql_inheritance (boolean)
-      
-       sql_inheritance configuration parameter
-      
-      inheritance
-      
-       
-        This controls the inheritance semantics, in particular whether
-        subtables are included by various commands by default. They were
-        not included in versions prior to 7.1. If you need the old
-        behavior you can set this variable to off, but in
-        the long run you are encouraged to change your applications to
-        use the ONLY key word to exclude subtables.
-        See  for more information about
-        inheritance.
-       
-      
-     
-
-     
-      default_with_oids (boolean)
-      
-       default_with_oids configuration parameter
-      
-      
-       
-        This controls whether CREATE TABLE and
-        CREATE TABLE AS include an OID column in
-        newly-created tables, if neither WITH OIDS
-        nor WITHOUT OIDS is specified. It also
-        determines whether OIDs will be included in tables created by
-        SELECT INTO. In PostgreSQL
-        8.1 default_with_oids is disabled by default; in
-        prior versions of PostgreSQL, it was on by default.
-       
-
-       
-        The use of OIDs in user tables is considered deprecated, so
-        most installations should leave this variable disabled.
-        Applications that require OIDs for a particular table should
-        specify WITH OIDS when creating the
-        table. This variable can be enabled for compatibility with old
-        applications that do not follow this behavior.
-       
-      
-     
-
-     
-      escape_string_warning (boolean)
-      stringsescape
-      
-       escape_string_warning configuration parameter
-      
-      
-       
-        When on, a warning is issued if a backslash (\)
-        appears in an ordinary string literal ('...'
-        syntax). The default is off.
-       
-       
-        Escape string syntax (E'...') should be used for
-        escapes, because in future versions of
-        PostgreSQL ordinary strings will have
-        the standard-conforming behavior of treating backslashes
-        literally.
-       
-      
-     
-
-     
-    
-    
-     Platform and Client Compatibility
-     
-
-     
-      transform_null_equals (boolean)
-      IS NULL
-      
-       transform_null_equals configuration parameter
-      
-      
-       
-        When on, expressions of the form expr =
-        NULL (or NULL =
-        expr) are treated as
-        expr IS NULL, that is, they
-        return true if expr evaluates to the null value,
-        and false otherwise. The correct SQL-spec-compliant behavior of
-        expr = NULL is to always
-        return null (unknown). Therefore this option defaults to
-        off.
-       
-
-       
-        However, filtered forms in Microsoft
-        Access generate queries that appear to use
-        expr = NULL to test for
-        null values, so if you use that interface to access the database you
-        might want to turn this option on.  Since expressions of the
-        form expr = NULL always
-        return the null value (using the correct interpretation) they are not
-        very useful and do not appear often in normal applications, so
-        this option does little harm in practice.  But new users are
-        frequently confused about the semantics of expressions
-        involving null values, so this option is not on by default.
-       
-
-       
-        Note that this option only affects the exact form = NULL,
-        not other comparison operators or other expressions
-        that are computationally equivalent to some expression
-        involving the equals operator (such as IN).
-        Thus, this option is not a general fix for bad programming.
-       
-
-       
-        Refer to  for related information.
-       
-      
-     
-
-     
-    
-   
-
-   
-    Preset Options
-
-    
-     The following parameters are read-only, and are determined
-     when PostgreSQL is compiled or when it is
-     installed. As such, they have been excluded from the sample
-     postgresql.conf file.  These options report
-     various aspects of PostgreSQL behavior
-     that may be of interest to certain applications, particularly
-     administrative front-ends.
-    
-
-    
-
-     
-      block_size (integer)
-      
-       block_size configuration parameter
-      
-      
-       
-        Reports the size of a disk block.  It is determined by the value
-        of BLCKSZ when building the server. The default
-        value is 8192 bytes.  The meaning of some configuration
-        variables (such as ) is
-        influenced by block_size. See 
-        linkend="runtime-config-resource"> for information.
-       
-      
-     
-
-     
-      integer_datetimes (boolean)
-      
-       integer_datetimes configuration parameter
-      
-      
-       
-        Reports whether PostgreSQL was built
-        with support for 64-bit-integer dates and times.  It is set by
-        configuring with --enable-integer-datetimes
-        when building PostgreSQL.  The
-        default value is off.
-       
-      
-     
-
-     
-      lc_collate (string)
-      
-       lc_collate configuration parameter
-      
-      
-       
-        Reports the locale in which sorting of textual data is done.
-        See  for more information.
-        The value is determined when the database cluster is initialized.
-       
-      
-     
-
-     
-      lc_ctype (string)
-      
-       lc_ctype configuration parameter
-      
-      
-       
-        Reports the locale that determines character classifications.
-        See  for more information.
-        The value is determined when the database cluster is initialized.
-        Ordinarily this will be the same as lc_collate,
-        but for special applications it might be set differently.
-       
-      
-     
-
-     
-      max_function_args (integer)
-      
-       max_function_args configuration parameter
-      
-      
-       
-        Reports the maximum number of function arguments. It is determined by
-        the value of FUNC_MAX_ARGS when building the server. The
-        default value is 100.
-       
-      
-     
-
-     
-      max_identifier_length (integer)
-      
-       max_identifier_length configuration parameter
-      
-      
-       
-        Reports the maximum identifier length. It is determined as one
-        less than the value of NAMEDATALEN when building
-        the server. The default value of NAMEDATALEN is
-        64; therefore the default
-        max_identifier_length is 63.
-       
-      
-     
-
-     
-      max_index_keys (integer)
-      
-       max_index_keys configuration parameter
-      
-      
-       
-        Reports the maximum number of index keys. It is determined by
-        the value of INDEX_MAX_KEYS when building the server. The
-        default value is 32.
-       
-      
-     
-
-     
-      server_encoding (string)
-      
-       server_encoding configuration parameter
-      
-      character set
-      
-       
-        Reports the database encoding (character set).
-        It is determined when the database is created.  Ordinarily,
-        clients need only be concerned with the value of 
-        linkend="guc-client-encoding">.
-       
-      
-     
-
-     
-      server_version (string)
-      
-       server_version configuration parameter
-      
-      
-       
-        Reports the version number of the server. It is determined by the
-        value of PG_VERSION when building the server.
-       
-      
-     
-
-     
-      standard_conforming_strings (boolean)
-      stringsescape
-      
-       standard_conforming_strings configuration parameter
-      
-      
-       
-        Reports whether ordinary string literals
-        ('...') treat backslashes literally, as specified in
-        the SQL standard.  The value is currently always off,
-        indicating that backslashes are treated as escapes.  It is planned
-        that this will change to on in a future
-        PostgreSQL release when string literal
-        syntax changes to meet the standard.  Applications may check this
-        parameter to determine how string literals will be processed.
-        The presence of this parameter can also be taken as an indication
-        that the escape string syntax (E'...') is supported.
-       
-      
-     
-
-    
-   
-
-   
-    Customized Options
-
-    
-     This feature was designed to allow options not normally known to
-     PostgreSQL to be added by add-on modules
-     (such as procedural languages).  This allows add-on modules to be
-     configured in the standard ways.
-    
-
-    
-
-     
-      custom_variable_classes (string)
-      
-       custom_variable_classes configuration parameter
-      
-      
-       
-        This variable specifies one or several class names to be used for
-        custom variables, in the form of a comma-separated list. A custom
-        variable is a variable not normally known
-        to PostgreSQL proper but used by some
-        add-on module.  Such variables must have names consisting of a class
-        name, a dot, and a variable name.  custom_variable_classes
-        specifies all the class names in use in a particular installation.
-        This option can only be set at server start or in the
-        postgresql.conf configuration file.
-       
-
-      
-     
-    
-
-    
-     The difficulty with setting custom variables in
-     postgresql.conf is that the file must be read before add-on
-     modules have been loaded, and so custom variables would ordinarily be
-     rejected as unknown.  When custom_variable_classes is set,
-     the server will accept definitions of arbitrary variables within each
-     specified class.  These variables will be treated as placeholders and
-     will have no function until the module that defines them is loaded. When a
-     module for a specific class is loaded, it will add the proper variable
-     definitions for its class name, convert any placeholder
-     values according to those definitions, and issue warnings for any
-     placeholders of its class that remain (which presumably would be
-     misspelled configuration variables).
-    
-
-    
-     Here is an example of what postgresql.conf might contain
-     when using custom variables:
-
-
-custom_variable_classes = 'plr,plperl'
-plr.path = '/usr/lib/R'
-plperl.use_strict = true
-plruby.use_strict = true        # generates error: unknown class name
-
-    
-   
-
-   
-    Developer Options
-
-    
-     The following options are intended for work on the
-     PostgreSQL source, and in some cases
-     to assist with recovery of severely damaged databases.  There
-     should be no reason to use them in a production database setup.
-     As such, they have been excluded from the sample
-     postgresql.conf file.  Note that many of these
-     options require special source compilation flags to work at all.
-    
-
-    
-     
-      debug_assertions (boolean)
-      
-       debug_assertions configuration parameter
-      
-      
-       
-        Turns on various assertion checks. This is a debugging aid. If
-        you are experiencing strange problems or crashes you might want
-        to turn this on, as it might expose programming mistakes. To use
-        this option, the macro USE_ASSERT_CHECKING
-        must be defined when PostgreSQL is
-        built (accomplished by the configure option
-        --enable-cassert). Note that
-        debug_assertions defaults to on
-        if PostgreSQL has been built with
-        assertions enabled.
-       
-      
-     
-
-     
-      pre_auth_delay (integer)
-      
-       pre_auth_delay configuration parameter
-      
-      
-       
-        If nonzero, a delay of this many seconds occurs just after a new
-        server process is forked, before it conducts the authentication
-        process.  This is intended to give an opportunity to attach to the
-        server process with a debugger to trace down misbehavior in
-        authentication.
-       
-      
-     
-
-     
-      trace_notify (boolean)
-      
-       trace_notify configuration parameter
-      
-      
-       
-        Generates a great amount of debugging output for the
-        LISTEN and NOTIFY
-        commands.   or
-         must be
-        DEBUG1 or lower to send this output to the
-        client or server log, respectively.
-       
-      
-     
-
-     
-      trace_locks (boolean)
-      trace_lwlocks (boolean)
-      trace_userlocks (boolean)
-      trace_lock_oidmin (boolean)
-      trace_lock_table (boolean)
-      debug_deadlocks (boolean)
-      log_btree_build_stats (boolean)
-      
-       
-        Various other code tracing and debugging options.
-       
-      
-     
-
-     
-      wal_debug (boolean)
-      
-       wal_debug configuration parameter
-      
-      
-       
-        If on, emit WAL-related debugging output. This option is
-        only available if the WAL_DEBUG macro was
-        defined when PostgreSQL was
-        compiled.
-       
-      
-     
-
-    
-      zero_damaged_pages (boolean)
-      
-       zero_damaged_pages configuration parameter
-      
-      
-       
-        Detection of a damaged page header normally causes
-        PostgreSQL to report an error, aborting the current
-        command.  Setting zero_damaged_pages to on causes
-        the system to instead report a warning, zero out the damaged page,
-        and continue processing.  This behavior will destroy data,
-        namely all the rows on the damaged page.  But it allows you to get
-        past the error and retrieve rows from any undamaged pages that may
-        be present in the table.  So it is useful for recovering data if
-        corruption has occurred due to hardware or software error.  You should
-        generally not set this on until you have given up hope of recovering
-        data from the damaged page(s) of a table.  The
-        default setting is off, and it can only be changed
-        by a superuser.
-       
-      
-     
-   
-  
-  
-   Short Options
-
-   
-    For convenience there are also single letter command-line option switches
-    available for some parameters. They are described in 
-    linkend="runtime-config-short-table">.
-   
-
-    
-     Short option key
-     
-      
-       
-        Short option
-        Equivalent
-       
-      
-
-      
-       
-        -B x
-        shared_buffers = x
-       
-       
-        -d x
-        log_min_messages = DEBUGx
-       
-       
-        -F
-        fsync = off
-       
-       
-        -h x
-        listen_addresses = x
-       
-       
-        -i
-        listen_addresses = '*'
-       
-       
-        -k x
-        unix_socket_directory = x
-       
-       
-        -l
-        ssl = on
-       
-       
-        -N x
-        max_connections = x
-       
-       
-        -p x
-        port = x
-       
-
-       
-        
-          -fb, -fh, -fi,
-          -fm, -fn,
-          -fs, -ft
-          id="fn.runtime-config-short">
-           
-            For historical reasons, these options must be passed to
-            the individual server process via the -o
-            postmaster option, for example,
-
-$ postmaster -o '-S 1024 -s'
-
-            or via PGOPTIONS from the client side, as
-            explained above.
-           
-          
-         
-         
-          enable_bitmapscan = off,
-          enable_hashjoin = off,
-          enable_indexscan = off,
-          enable_mergejoin = off,
-          enable_nestloop = off,
-          enable_seqscan = off,
-          enable_tidscan = off
-         
-       
-
-       
-        -s
-        log_statement_stats = on
-       
-
-       
-        -S x
-        
-        work_mem = x
-       
-
-       
-        -tpa, -tpl, -te
-        log_parser_stats = on,
-        log_planner_stats = on, 
-        log_executor_stats = on
-       
-      
-     
-    
-
-  
- 
-
-
  
   Managing Kernel Resources
 




This is the main PostgreSQL git repository.
RSS
Atom



window.onload = function () {
	var tz_cookie = { name: 'gitweb_tz', expires: 14, path: '/' };
	onloadTZSetup('local', tz_cookie, 'datetime');
};

diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 5af562a6635fecf531be01e97b6be7582e939c9c..3a8745df90955e6ce0736cb85ca6e989e0a84a88 100644 (file)
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -1,5 +1,5 @@
 
 
 
@@ -451,4224 +451,6 @@ psql: could not connect to server: No such file or directory
    
   
 
-  
-   Run-time Configuration
-
-   
-    configuration
-    of the server
-   
-
-   
-    There are a lot of configuration parameters that affect the
-    behavior of the database system. In this subsection, we describe
-    how to set configuration parameters; the following subsections
-    discuss each parameter in detail.
-   
-
-   
-    All parameter names are case-insensitive. Every parameter takes a
-    value of one of four types: boolean, integer, floating point,
-    or string. Boolean values may be written as ON,
-    OFF, TRUE,
-    FALSE, YES,
-    NO, 1, 0
-    (all case-insensitive) or any unambiguous prefix of these.
-   
-
-   
-    One way to set these parameters is to edit the file
-    postgresql.confpostgresql.conf,
-    which is normally kept in the data directory. (initdb
-    installs a default copy there.) An example of what this file might look
-    like is:
-
-# This is a comment
-log_connections = yes
-log_destination = 'syslog'
-search_path = '$user, public'
-
-    One parameter is specified per line. The equal sign between name and
-    value is optional. Whitespace is insignificant and blank lines are
-    ignored. Hash marks (#) introduce comments
-    anywhere.  Parameter values that are not simple identifiers or
-    numbers must be single-quoted.
-   
-
-   
-    
-     SIGHUP
-    
-    The configuration file is reread whenever the
-    postmaster process receives a
-    SIGHUP signal (which is most easily sent by means
-    of pg_ctl reload). The postmaster
-    also propagates this signal to all currently running server
-    processes so that existing sessions also get the new
-    value. Alternatively, you can send the signal to a single server
-    process directly.  Some parameters can only be set at server start;
-    any changes to their entries in the configuration file will be ignored
-    until the server is restarted.
-   
-
-   
-    A second way to set these configuration parameters is to give them
-    as a command line option to the postmaster, such as:
-
-postmaster -c log_connections=yes -c log_destination='syslog'
-
-    Command-line options override any conflicting settings in
-    postgresql.conf.  Note that this means you won't
-    be able to change the value on-the-fly by editing
-    postgresql.conf, so while the command-line
-    method may be convenient, it can cost you flexibility later.
-   
-
-   
-    Occasionally it is useful to give a command line option to
-    one particular session only. The environment variable
-    PGOPTIONS can be used for this purpose on the
-    client side:
-
-env PGOPTIONS='-c geqo=off' psql
-
-    (This works for any libpq-based client application, not
-    just psql.) Note that this won't work for
-    parameters that are fixed when the server is started or that must be
-    specified in postgresql.conf.
-   
-
-   
-    Furthermore, it is possible to assign a set of option settings to
-    a user or a database.  Whenever a session is started, the default
-    settings for the user and database involved are loaded.  The
-    commands 
-    and ,
-    respectively, are used to configure these settings.  Per-database
-    settings override anything received from the
-    postmaster command-line or the configuration
-    file, and in turn are overridden by per-user settings; both are
-    overridden by per-session options.
-   
-
-   
-    Some parameters can be changed in individual SQL
-    sessions with the 
-    command, for example:
-
-SET ENABLE_SEQSCAN TO OFF;
-
-    If SET is allowed, it overrides all other sources of
-    values for the parameter. Some parameters cannot be changed via
-    SET: for example, if they control behavior that
-    cannot reasonably be changed without restarting
-    PostgreSQL.  Also, some parameters can
-    be modified via SET or ALTER by superusers,
-    but not by ordinary users.
-   
-
-   
-    The 
-    command allows inspection of the current values of all parameters.
-   
-
-   
-    The virtual table pg_settings
-    (described in ) also allows
-    displaying and updating session run-time parameters.  It is equivalent
-    to SHOW and SET, but can be more convenient
-    to use because it can be joined with other tables, or selected from using
-    any desired selection condition.
-   
-    
-   
-    File Locations
-
-     
-      In addition to the postgresql.conf file
-      already mentioned, PostgreSQL uses
-      two other manually-edited configuration files, which control
-      client authentication (their use is discussed in 
-      linkend="client-authentication">).
-      By default, all three configuration files are stored
-      in the database cluster's data directory.  The options described
-      in this subsection allow the configuration files to be placed elsewhere.
-      (Doing so can ease administration.  In particular it is often
-      easier to ensure that the configuration files are properly backed-up
-      when they are kept separate.)
-     
-
-     
-     
-      data_directory (string)
-      
-       data_directory configuration parameter
-      
-      
-       
-         Specifies the directory to use for data storage.
-         This option can only be set at server start.
-       
-      
-     
-
-     
-      config_file (string)
-      
-       config_file configuration parameter
-      
-      
-       
-         Specifies the main server configuration file
-         (customarily called postgresql.conf).
-         This option can only be set on the postmaster command line.
-       
-      
-     
-
-     
-      hba_file (string)
-      
-       hba_file configuration parameter
-      
-      
-       
-         Specifies the configuration file for host-based authentication
-         (customarily called pg_hba.conf).
-         This option can only be set at server start.
-       
-      
-     
-
-     
-      ident_file (string)
-      
-       ident_file configuration parameter
-      
-      
-       
-         Specifies the configuration file for
-         ident authentication
-         (customarily called pg_ident.conf).
-         This option can only be set at server start.
-       
-      
-     
-
-     
-      external_pid_file (string)
-      
-       external_pid_file configuration parameter
-      
-      
-       
-        Specifies the name of an additional process-id (PID) file that the
-        postmaster should create for use by server
-        administration programs.
-        This option can only be set at server start.
-       
-      
-     
-     
-
-     
-      In a default installation, none of the above options are set explicitly.
-      Instead, the
-      data directory is specified by the -D command-line
-      option or the PGDATA environment variable, and the
-      configuration files are all found within the data directory.
-     
-
-     
-      If you wish to keep the configuration files elsewhere than the
-      data directory, the postmaster's -D
-      command-line option or PGDATA environment variable
-      must point to the directory containing the configuration files,
-      and the data_directory option must be set in
-      postgresql.conf (or on the command line) to show
-      where the data directory is actually located.  Notice that
-      data_directory overrides -D and
-      PGDATA for the location
-      of the data directory, but not for the location of the configuration
-      files.
-     
-
-     
-      If you wish, you can specify the configuration file names and locations
-      individually using the options config_file,
-      hba_file and/or ident_file.
-      config_file can only be specified on the 
-      postmaster command line, but the others can be
-      set within the main configuration file.  If all three options plus
-      data_directory are explicitly set, then it is not necessary
-      to specify -D or PGDATA.
-     
-
-     
-      When setting any of these options, a relative path will be interpreted
-      with respect to the directory in which the postmaster
-      is started.
-     
-   
-
-   
-    Connections and Authentication
-
-    
-     Connection Settings
-
-     
-
-     
-      listen_addresses (string)
-      
-       listen_addresses configuration parameter
-      
-      
-       
-         Specifies the TCP/IP address(es) on which the server is
-         to listen for connections from client applications.  
-         The value takes the form of a comma-separated list of host names
-         and/or numeric IP addresses.  The special entry *
-         corresponds to all available IP interfaces.
-         If the list is empty, the server does not listen on any IP interface
-         at all, in which case only Unix-domain sockets can be used to connect
-         to it.
-         The default value is localhost,
-         which allows only local loopback connections to be made.
-         This parameter can only be set at server start.
-       
-      
-     
-
-     
-      port (integer)
-      
-       port configuration parameter
-      
-      
-       
-        The TCP port the server listens on; 5432 by default.  Note that the
-        same port number is used for all IP addresses the server listens on.
-        This parameter can only be set at server start.
-       
-      
-     
-
-     
-      max_connections (integer)
-      
-       max_connections configuration parameter
-      
-      
-       
-        Determines the maximum number of concurrent connections to the
-        database server. The default is typically 100, but may be less
-        if your kernel settings will not support it (as determined
-        during initdb).  This parameter can only be
-        set at server start.
-       
-
-       
-        Increasing this parameter may cause PostgreSQL
-        to request more System V shared
-        memory or semaphores than your operating system's default configuration
-        allows. See  for information on how to
-        adjust those parameters, if necessary.
-       
-      
-     
-     
-     
-     xreflabel="superuser_reserved_connections">
-      superuser_reserved_connections
-      (integer)
-      
-       superuser_reserved_connections configuration parameter
-      
-      
-       
-        Determines the number of connection slots that
-        are reserved for connections by PostgreSQL
-        superusers.  At most 
-        connections can ever be active simultaneously.  Whenever the
-        number of active concurrent connections is at least
-        max_connections minus
-        superuser_reserved_connections, new
-        connections will be accepted only for superusers.
-       
-
-       
-        The default value is 2. The value must be less than the value of
-        max_connections. This parameter can only be
-        set at server start.
-       
-      
-     
-
-     
-      unix_socket_directory (string)
-      
-       unix_socket_directory configuration parameter
-      
-      
-       
-        Specifies the directory of the Unix-domain socket on which the
-        server is to listen for
-        connections from client applications.  The default is normally
-        /tmp, but can be changed at build time.
-        This parameter can only be set at server start.
-       
-      
-     
-
-     
-      unix_socket_group (string)
-      
-       unix_socket_group configuration parameter
-      
-      
-       
-        Sets the owning group of the Unix-domain socket.  (The owning
-        user of the socket is always the user that starts the
-        server.)  In combination with the option
-        unix_socket_permissions this can be used as
-        an additional access control mechanism for Unix-domain connections.
-        By default this is the empty string, which uses the default
-        group for the current user.  This option can only be set at
-        server start.
-       
-      
-     
-
-     
-      unix_socket_permissions (integer)
-      
-       unix_socket_permissions configuration parameter
-      
-      
-       
-        Sets the access permissions of the Unix-domain socket.  Unix-domain
-        sockets use the usual Unix file system permission set.
-        The option value is expected to be a numeric mode
-        specification in the form accepted by the
-        chmod and umask
-        system calls.  (To use the customary octal format the number
-        must start with a 0 (zero).)
-       
-
-       
-        The default permissions are 0777, meaning
-        anyone can connect. Reasonable alternatives are
-        0770 (only user and group, see also
-        unix_socket_group) and 0700
-        (only user). (Note that for a Unix-domain socket, only write
-        permission matters and so there is no point in setting or revoking
-        read or execute permissions.)
-       
-
-       
-        This access control mechanism is independent of the one
-        described in .
-       
-
-       
-        This option can only be set at server start.
-       
-      
-     
-     
-     
-      bonjour_name (string)
-      
-       bonjour_name configuration parameter
-      
-      
-       
-        Specifies the Bonjour broadcast
-        name.  By default, the computer name is used, specified as an
-        empty string ''.  This option is ignored if the server was not
-        compiled with Bonjour support.  This
-        option can only be set at server start.
-       
-      
-     
-     
-     
-      tcp_keepalives_idle (integer)
-      
-       tcp_keepalives_idle configuration parameter
-      
-      
-       
-        On systems that support the TCP_KEEPIDLE socket option, specifies the
-        number of seconds between sending keepalives on an otherwise idle
-        connection. A value of 0 uses the system default. If TCP_KEEPIDLE is
-        not supported, this parameter must be 0. This option is ignored for
-        connections made via a Unix-domain socket.
-       
-      
-     
-     
-     
-      tcp_keepalives_interval (integer)
-      
-       tcp_keepalives_interval configuration parameter
-      
-      
-       
-        On systems that support the TCP_KEEPINTVL socket option, specifies how
-        long, in seconds, to wait for a response to a keepalive before
-        retransmitting. A value of 0 uses the system default. If TCP_KEEPINTVL
-        is not supported, this parameter must be 0. This option is ignored
-        for connections made via a Unix-domain socket.
-       
-      
-     
-     
-     
-      tcp_keepalives_count (integer)
-      
-       tcp_keepalives_count configuration parameter
-      
-      
-       
-        On systems that support the TCP_KEEPCNT socket option, specifies how
-        many keepalives may be lost before the connection is considered dead. 
-        A value of 0 uses the system default. If TCP_KEEPINTVL is not
-        supported, this parameter must be 0.
-       
-      
-     
-     
-     
-     
-     
-     Security and Authentication
-     
-     
-     
-      authentication_timeout (integer)
-      timeoutclient authentication
-      client authenticationtimeout during
-      
-       authentication_timeout configuration parameter
-      
-
-      
-       
-        Maximum time to complete client authentication, in seconds. If a
-        would-be client has not completed the authentication protocol in
-        this much time, the server breaks the connection. This prevents
-        hung clients from occupying a connection indefinitely. This
-        option can only be set at server start or in the
-        postgresql.conf file. The default is 60.
-       
-      
-     
-     
-     
-      ssl (boolean)
-      
-       ssl configuration parameter
-      
-      
-       
-        Enables SSL connections. Please read
-         before using this. The default
-        is off. This parameter can only be set at server
-        start.
-       
-      
-     
-
-     
-      password_encryption (boolean)
-      
-       password_encryption configuration parameter
-      
-      
-       
-        When a password is specified in 
-        linkend="sql-createuser" endterm="sql-createuser-title"> or
-        
-        without writing either ENCRYPTED or
-        UNENCRYPTED, this option determines whether the
-        password is to be encrypted. The default is on
-        (encrypt the password).
-       
-      
-     
-
-     
-      krb_server_keyfile (string)
-      
-       krb_server_keyfile configuration parameter
-      
-      
-       
-        Sets the location of the Kerberos server key file. See
-         for details. This parameter
-        can only be set at server start.
-       
-      
-     
-
-     
-      krb_srvname (string)
-      
-       krb_srvname configuration parameter
-      
-      
-       
-        Sets the Kerberos service name. See 
-        for details.  This parameter can only be set at server start.
-       
-      
-     
-
-     
-      krb_server_hostname (string)
-      
-       krb_server_hostname configuration parameter
-      
-      
-       
-        Sets the hostname part of the service principal.
-        This, combined with krb_srvname, is used to generate
-        the complete service principal, i.e.
-        krb_server_hostname/krb_server_hostname@REALM.
-       
-       
-        If not set, the default is to allow any service principal matching an entry
-        in the keytab.  See  for details.
-        This parameter can only be set at server start.
-       
-      
-     
-
-     
-      krb_caseins_users (boolean)
-      
-       krb_caseins_users configuration parameter
-      
-      
-       
-        Sets if Kerberos usernames should be treated case-insensitively.
-        The default is off (case sensitive). This parameter
-        can only be set at server start.
-       
-      
-     
-
-     
-      db_user_namespace (boolean)
-      
-       db_user_namespace configuration parameter
-      
-      
-       
-        This enables per-database user names.  It is off by default.
-       
-
-       
-        If this is on, you should create users as username@dbname.
-        When username is passed by a connecting client,
-        @ and the database name are appended to the user
-        name and that database-specific user name is looked up by the
-        server. Note that when you create users with names containing
-        @ within the SQL environment, you will need to
-        quote the user name.
-       
-
-       
-        With this option enabled, you can still create ordinary global
-        users.  Simply append @ when specifying the user
-        name in the client.  The @ will be stripped off
-        before the user name is looked up by the server.
-       
-
-       
-        
-         This feature is intended as a temporary measure until a
-         complete solution is found.  At that time, this option will
-         be removed.
-        
-       
-      
-     
-
-    
-    
-   
-
-   
-    Resource Consumption
-
-    
-     Memory
-
-     
-     
-      shared_buffers (integer)
-      
-       shared_buffers configuration parameter
-      
-      
-       
-        Sets the number of shared memory buffers used by the database
-        server. The default is typically 1000, but may be less if your
-        kernel settings will not support it (as determined during
-        initdb).  Each buffer is 8192 bytes, unless a
-        different value of BLCKSZ was chosen when building
-        the server.  This setting must be at least 16, as well as at
-        least twice the value of ;
-        however, settings significantly higher than the minimum are
-        usually needed for good performance.  Values of a few thousand
-        are recommended for production installations.  This option can
-        only be set at server start.
-       
-
-       
-        Increasing this parameter may cause PostgreSQL
-        to request more System V shared
-        memory than your operating system's default configuration
-        allows. See  for information on how to
-        adjust those parameters, if necessary.
-       
-      
-     
-
-     
-      temp_buffers (integer)
-      
-       temp_buffers configuration parameter
-      
-      
-       
-        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 1000.  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.
-       
-
-       
-        A session will allocate temporary buffers as needed up to the limit
-        given by temp_buffers.  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 temp_buffers.  However if a buffer is
-        actually used an additional 8192 bytes will be consumed for it
-        (or in general, BLCKSZ bytes).
-       
-      
-     
-
-     
-      max_prepared_transactions (integer)
-      
-       max_prepared_transactions configuration parameter
-      
-      
-       
-        Sets the maximum number of transactions that can be in the
-        prepared state simultaneously (see 
-        linkend="sql-prepare-transaction"
-        endterm="sql-prepare-transaction-title">).
-        Setting this parameter to zero disables the prepared-transaction
-        feature.
-        The default is 5.
-        This option can only be set at server start.
-       
-
-       
-        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 max_prepared_transactions to be at least
-        as large as , to avoid unwanted
-        failures at the prepare step.
-       
-
-       
-        Increasing this parameter may cause PostgreSQL
-        to request more System V shared
-        memory than your operating system's default configuration
-        allows. See  for information on how to
-        adjust those parameters, if necessary.
-       
-      
-     
-
-     
-      work_mem (integer)
-      
-       work_mem configuration parameter
-      
-      
-       
-        Specifies the amount of memory to be used by internal sort operations
-        and hash tables before switching to temporary disk files. The value is
-        specified in kilobytes, and defaults to 1024 kilobytes (1 MB).
-        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 work_mem; it is necessary to
-        keep this fact in mind when choosing the value. Sort operations are
-        used for ORDER BY, DISTINCT, and
-        merge joins.
-        Hash tables are used in hash joins, hash-based aggregation, and
-        hash-based processing of IN subqueries.
-       
-      
-     
-     
-     
-      maintenance_work_mem (integer)
-      
-       maintenance_work_mem configuration parameter
-      
-      
-       
-        Specifies the maximum amount of memory to be used in maintenance
-        operations, such as VACUUM, CREATE
-        INDEX, and ALTER TABLE ADD FOREIGN KEY.
-        The value is specified in kilobytes, and defaults to 16384 kilobytes
-        (16 MB).  Since only one of these operations can be executed at 
-        a time by a database session, and an installation normally doesn't
-        have very many of them happening concurrently, it's safe to set this
-        value significantly larger than work_mem.  Larger
-        settings may improve performance for vacuuming and for restoring
-        database dumps.
-       
-      
-     
-
-     
-      max_stack_depth (integer)
-      
-       max_stack_depth configuration parameter
-      
-      
-       
-        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 ulimit -s 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.  Setting the parameter higher than
-        the actual kernel limit will mean that a runaway recursive function
-        can crash an individual backend process.  The default setting is
-        2048 KB (two megabytes), which is conservatively small and unlikely
-        to risk crashes.  However, it may be too small to allow execution
-        of complex functions.
-       
-      
-     
-
-     
-     
-     
-     Free Space Map
-
-     
-      free space map
-     
-
-     
-      These parameters control the size of the shared free space
-      map, 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 PostgreSQL
-      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 VACUUM VERBOSE 
-      command can help in determining if the current settings are adequate.
-      A NOTICE message is also printed during such an operation
-      if the current settings are too low.
-     
-
-     
-      Increasing these parameters may cause PostgreSQL
-      to request more System V shared
-      memory than your operating system's default configuration
-      allows. See  for information on how to
-      adjust those parameters, if necessary.
-     
-
-     
-     
-      max_fsm_pages (integer)
-      
-       max_fsm_pages configuration parameter
-      
-      
-       
-        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 more than
-        16 * max_fsm_relations.  The default is 20000.
-        This option can only be set at server start.
-       
-      
-     
-
-     
-      max_fsm_relations (integer)
-      
-       max_fsm_relations configuration parameter
-      
-      
-       
-        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 1000.
-        This option can only be set at server start.
-       
-      
-     
-     
-     
-     
-     
-     Kernel Resource Usage
-     
-
-     
-      max_files_per_process (integer)
-      
-       max_files_per_process configuration parameter
-      
-      
-       
-        Sets the maximum number of simultaneously open files allowed to each
-        server subprocess. The default is 1000. 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 Too many open
-        files failures, try reducing this setting.
-        This option can only be set at server start.
-       
-      
-     
-     
-     
-      preload_libraries (string)
-      
-       preload_libraries configuration parameter
-      
-      
-       
-        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
-        '$libdir/mylib:mylib_init' would cause
-        mylib to be preloaded and mylib_init
-        to be executed. If more than one library is to be loaded,
-        separate their names with commas.
-       
-
-       
-        If a specified library or initialization function is not found,
-        the server will fail to start.
-       
-
-       
-        PostgreSQL procedural language
-        libraries may be preloaded in this way, typically by using the
-        syntax '$libdir/plXXX:plXXX_init' where
-        XXX is pgsql, perl,
-        tcl, or python.
-       
-
-       
-        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.
-       
-      
-     
-
-     
-    
-
-    
-     
-       Cost-Based Vacuum Delay
-     
-
-     
-      During the execution of 
-      endterm="sql-vacuum-title"> and 
-      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
-      vacuum_cost_limit), the process performing
-      the operation will sleep for a while (specified by
-      vacuum_cost_delay). Then it will reset the
-      counter and continue execution.
-     
-
-     
-      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
-      VACUUM and ANALYZE 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.
-     
-
-     
-      This feature is disabled by default. To enable it, set the
-      vacuum_cost_delay variable to a nonzero
-      value.
-     
-
-     
-      
-       vacuum_cost_delay (integer)
-       
-        vacuum_cost_delay configuration parameter
-       
-       
-        
-         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
-         vacuum_cost_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.
-        
-       
-      
-
-      
-       vacuum_cost_page_hit (integer)
-       
-        vacuum_cost_page_hit configuration parameter
-       
-       
-        
-         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.
-        
-       
-      
-
-      
-       vacuum_cost_page_miss (integer)
-       
-        vacuum_cost_page_miss configuration parameter
-       
-       
-        
-         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.
-        
-       
-      
-
-      
-       vacuum_cost_page_dirty (integer)
-       
-        vacuum_cost_page_dirty configuration parameter
-       
-       
-        
-         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.
-        
-       
-      
-
-      
-       vacuum_cost_limit (integer)
-       
-        vacuum_cost_limit configuration parameter
-       
-       
-        
-         The accumulated cost that will cause the vacuuming process to sleep.
-         The default value is 200.
-        
-       
-      
-     
-
-     
-      
-       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 vacuum_cost_delay *
-       accumulated_balance /
-       vacuum_cost_limit with a maximum of
-       vacuum_cost_delay * 4.
-      
-     
-
-    
-
-    
-     Background Writer
-
-     
-      Beginning in PostgreSQL 8.0, there is a separate server
-      process called the background writer, whose sole function
-      is to issue writes of 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 section can be used to tune
-      the behavior for local needs.
-     
-
-     
-      
-       bgwriter_delay (integer)
-       
-        bgwriter_delay configuration parameter
-       
-       
-        
-         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 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 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 only be set at server start or in the
-         postgresql.conf file.
-        
-       
-      
-
-      
-       bgwriter_lru_percent (floating point)
-       
-        bgwriter_lru_percent configuration parameter
-       
-       
-        
-         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
-         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 only be set at server start or in the
-         postgresql.conf file.
-        
-       
-      
-
-      
-       bgwriter_lru_maxpages (integer)
-       
-        bgwriter_lru_maxpages configuration parameter
-       
-       
-        
-         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 only be set at server start or in the
-         postgresql.conf file.
-        
-       
-      
-
-      
-       bgwriter_all_percent (floating point)
-       
-        bgwriter_all_percent configuration parameter
-       
-       
-        
-         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
-         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 bgwriter_delay
-         setting, this will allow the entire shared buffer pool to be scanned
-         about once per minute.
-         This option can only be set at server start or in the
-         postgresql.conf file.
-        
-       
-      
-
-      
-       bgwriter_all_maxpages (integer)
-       
-        bgwriter_all_maxpages configuration parameter
-       
-       
-        
-         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 only be set at server start or in the
-         postgresql.conf file.
-        
-       
-      
-     
-
-     
-      Smaller values of bgwriter_all_percent and
-      bgwriter_all_maxpages 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 bgwriter_lru_percent and
-      bgwriter_lru_maxpages 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 maxpages values and/or both
-      percent values to zero.
-     
-    
-
-   
-
-   
-    Write Ahead Log
-
-   
-    See also  for details on WAL
-    tuning.
-   
-
-    
-     Settings
-     
-     
-     
-      
-       fsync configuration parameter
-      
-      fsync (boolean)
-      
-       
-        If this option is on, the PostgreSQL server
-        will use the fsync() system call in several places
-        to make sure that updates are physically written to disk. This
-        insures that a database cluster will recover to a
-        consistent state after an operating system or hardware crash.
-       
-
-       
-        However, using fsync() results in a
-        performance penalty: when a transaction is committed,
-        PostgreSQL must wait for the
-        operating system to flush the write-ahead log to disk.  When
-        fsync is disabled, the operating system is
-        allowed to do its best in buffering, ordering, and delaying
-        writes. This can result in significantly improved performance.
-        However, if the system crashes, the results of the last few
-        committed transactions may be lost in part or whole. In the
-        worst case, unrecoverable data corruption may occur.
-        (Crashes of the database server itself are not
-        a risk factor here.  Only an operating-system-level crash
-        creates a risk of corruption.)
-       
-
-       
-        Due to the risks involved, there is no universally correct
-        setting for fsync. Some administrators
-        always disable fsync, while others only
-        turn it off for bulk loads, where there is a clear restart
-        point if something goes wrong, whereas some administrators
-        always leave fsync enabled. The default is
-        to enable fsync, for maximum reliability.
-        If you trust your operating system, your hardware, and your
-        utility company (or your battery backup), you can consider
-        disabling fsync.
-       
-
-       
-        This option can only be set at server start or in the
-        postgresql.conf file.  If this option
-        is off, consider also turning off 
-        guc-full-page-writes.
-       
-      
-     
-     
-     
-      wal_sync_method (string)
-      
-       wal_sync_method configuration parameter
-      
-      
-       
-        Method used for forcing WAL updates out to disk.  Possible
-        values are:
-       
-       
-        
-        
-         open_datasync (write WAL files with open() option O_DSYNC)
-        
-        
-        
-        
-         fdatasync (call fdatasync() at each commit),
-        
-        
-        
-        
-         fsync (call fsync() at each commit)
-        
-        
-        
-        
-         fsync_writethrough (force write-through of any disk write cache)
-        
-        
-        
-        
-         open_sync (write WAL files with open() option O_SYNC)
-        
-        
-       
-       
-        Not all of these choices are available on all platforms.
-        The top-most supported option is used as the default.
-        If fsync is off then this setting is irrelevant.
-        This option can only be set at server start or in the
-        postgresql.conf file.
-       
-      
-     
-     
-     
-      
-       full_page_writes configuration parameter
-      
-      full_page_writes (boolean)
-      
-       
-        A page write in process during an operating system crash might
-        be only partially written to disk, leading to an on-disk page
-        that contains a mix of old and new data. During recovery, the
-        row changes stored in WAL are not enough to completely restore
-        the page.
-       
-
-       
-        When this option is on, the PostgreSQL server
-        writes full pages to WAL when they are first modified after a
-        checkpoint so full recovery is possible. Turning this option off
-        might lead to a corrupt system after an operating system crash
-        or power failure because uncorrected partial pages might contain
-        inconsistent or corrupt data. The risks are less but similar to
-        fsync.
-       
-
-       
-        This option can only be set at server start or in the
-        postgresql.conf file.  The default is
-        on.
-       
-      
-     
-     
-     
-      wal_buffers (integer)
-      
-       wal_buffers configuration parameter
-      
-      
-       
-        Number of disk-page buffers allocated in shared memory for WAL data.
-        The default is 8.  The setting need only be large enough to hold
-        the amount of WAL data generated by one typical transaction, since
-        the data is flushed to disk at every transaction commit.
-        This option can only be set at server start.
-       
-
-       
-        Increasing this parameter may cause PostgreSQL
-        to request more System V shared
-        memory than your operating system's default configuration
-        allows. See  for information on how to
-        adjust those parameters, if necessary.
-       
-      
-     
-                
-     
-      commit_delay (integer)
-      
-       commit_delay configuration parameter
-      
-      
-       
-        Time delay between writing a commit record to the WAL buffer
-        and flushing the buffer out to disk, in microseconds. A
-        nonzero delay can allow multiple transactions to be committed
-        with only one fsync() system call, if
-        system load is high enough that additional transactions become
-        ready to commit within the given interval. But the delay is
-        just wasted if no other transactions become ready to
-        commit. Therefore, the delay is only performed if at least
-        commit_siblings other transactions are
-        active at the instant that a server process has written its
-        commit record. The default is zero (no delay).
-       
-      
-     
-
-     
-      commit_siblings (integer)
-      
-       commit_siblings configuration parameter
-      
-      
-       
-        Minimum number of concurrent open transactions to require
-        before performing the commit_delay delay. A larger
-        value makes it more probable that at least one other
-        transaction will become ready to commit during the delay
-        interval. The default is five.
-       
-      
-     
-
-     
-     
-     
-     Checkpoints
-
-    
-     
-      checkpoint_segments (integer)
-      
-       checkpoint_segments configuration parameter
-      
-      
-       
-        Maximum distance between automatic WAL checkpoints, in log
-        file segments (each segment is normally 16 megabytes). The
-        default is three.  This option can only be set at server start
-        or in the postgresql.conf file.
-       
-      
-     
-
-     
-      checkpoint_timeout (integer)
-      
-       checkpoint_timeout configuration parameter
-      
-      
-       
-        Maximum time between automatic WAL checkpoints, in
-        seconds. The default is 300 seconds.  This option can only be
-        set at server start or in the postgresql.conf
-        file.
-       
-      
-     
-
-     
-      checkpoint_warning (integer)
-      
-       checkpoint_warning configuration parameter
-      
-      
-       
-        Write a message to the server log if checkpoints caused by
-        the filling of checkpoint segment files happen closer together
-        than this many seconds.  The default is 30 seconds.
-        Zero turns off the warning.
-       
-      
-     
-
-     
-     
-     
-     Archiving
-
-    
-     
-      archive_command (string)
-      
-       archive_command configuration parameter
-      
-      
-       
-        The shell command to execute to archive a completed segment of
-        the WAL file series. If this is an empty string (the default),
-        WAL archiving is disabled. Any %p in the string is
-        replaced by the absolute path of the file to archive, and any
-        %f is replaced by the file name only. Use
-        %% to embed an actual % character in the
-        command. For more information see 
-        linkend="backup-archiving-wal">. This option can only be set at
-        server start or in the postgresql.conf
-        file.
-       
-       
-        It is important for the command to return a zero exit status if
-        and only if it succeeds.  Examples:
-
-archive_command = 'cp "%p" /mnt/server/archivedir/"%f"'
-archive_command = 'copy "%p" /mnt/server/archivedir/"%f"'  # Windows
-
-       
-      
-     
-     
-     
-    
-   
-
-   
-    Query Planning
-
-    
-     Planner Method Configuration
-
-      
-       These configuration parameters provide a crude method of
-       influencing the query plans chosen by the query optimizer. If
-       the default plan chosen by the optimizer for a particular query
-       is not optimal, a temporary solution may be found by using one
-       of these configuration parameters to force the optimizer to
-       choose a different plan.  Turning one of these settings off
-       permanently is seldom a good idea, however.
-       Better ways to improve the quality of the
-       plans chosen by the optimizer include adjusting the 
-       linkend="runtime-config-query-constants"
-       endterm="runtime-config-query-constants-title">, running 
-       linkend="sql-analyze" endterm="sql-analyze-title"> more
-       frequently, increasing the value of the 
-       linkend="guc-default-statistics-target"> configuration parameter,
-       and increasing the amount of statistics collected for
-       specific columns using ALTER TABLE SET
-       STATISTICS.
-      
-
-     
-     
-      enable_bitmapscan (boolean)
-      
-       bitmap scan
-      
-      
-       enable_bitmapscan configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of bitmap-scan plan
-        types. The default is on.
-       
-      
-     
-
-     
-      enable_hashagg (boolean)
-      
-       enable_hashagg configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of hashed
-        aggregation plan types. The default is on.
-       
-      
-     
-
-     
-      enable_hashjoin (boolean)
-      
-       enable_hashjoin configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of hash-join plan
-        types. The default is on.
-       
-      
-     
-
-     
-      enable_indexscan (boolean)
-      
-       index scan
-      
-      
-       enable_indexscan configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of index-scan plan
-        types. The default is on.
-       
-      
-     
-
-     
-      enable_mergejoin (boolean)
-      
-       enable_mergejoin configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of merge-join plan
-        types. The default is on.
-       
-      
-     
-
-     
-      enable_nestloop (boolean)
-      
-       enable_nestloop configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of nested-loop join
-        plans. It's not possible to suppress nested-loop joins entirely,
-        but turning this variable off discourages the planner from using
-        one if there are other methods available. The default is
-        on.
-       
-      
-     
-
-     
-      enable_seqscan (boolean)
-      
-       sequential scan
-      
-      
-       enable_seqscan configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of sequential scan
-        plan types. It's not possible to suppress sequential scans
-        entirely, but turning this variable off discourages the planner
-        from using one if there are other methods available. The
-        default is on.
-       
-      
-     
-
-     
-      enable_sort (boolean)
-      
-       enable_sort configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of explicit sort
-        steps. It's not possible to suppress explicit sorts entirely,
-        but turning this variable off discourages the planner from
-        using one if there are other methods available. The default
-        is on.
-       
-      
-     
-
-     
-      enable_tidscan (boolean)
-      
-       enable_tidscan configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of TID
-        scan plan types. The default is on.
-       
-      
-     
-     
-     
-     
-     
-     
-      Planner Cost Constants
-     
-
-   
-    
-     Unfortunately, there is no well-defined method for determining
-     ideal values for the family of cost variables that
-     appear below. You are encouraged to experiment and share
-     your findings.
-    
-   
-
-     
-     
-     
-      effective_cache_size (floating point)
-      
-       effective_cache_size configuration parameter
-      
-      
-       
-        Sets the planner's assumption about the effective size of the
-        disk cache that is available to a single index scan.  This is
-        factored into estimates of the cost of using an index; a higher
-        value makes it more likely index scans will be used, a lower
-        value makes it more likely sequential scans will be used. When
-        setting this parameter you should consider both
-        PostgreSQL's shared buffers and the
-        portion of the kernel's disk cache that will be used for
-        PostgreSQL data files.  Also, take into
-        account the expected number of concurrent queries using different
-        indexes, since they will have to share the available space.
-        This parameter has no effect on the size of shared memory
-        allocated by PostgreSQL, nor does it reserve kernel disk cache;
-        it is used only for estimation purposes.
-        The value is measured in disk pages, which are
-        normally 8192 bytes each. The default is 1000.
-       
-      
-     
-
-     
-      random_page_cost (floating point)
-      
-       random_page_cost configuration parameter
-      
-      
-       
-        Sets the planner's estimate of the cost of a
-        nonsequentially fetched disk page. This is measured as a
-        multiple of the cost of a sequential page fetch. A higher
-        value makes it more likely a sequential scan will be used, a
-        lower value makes it more likely an index scan will be
-        used. The default is four.
-       
-      
-     
-
-     
-      cpu_tuple_cost (floating point)
-      
-       cpu_tuple_cost configuration parameter
-      
-      
-       
-        Sets the planner's estimate of the cost of processing
-        each row during a query. This is measured as a fraction of
-        the cost of a sequential page fetch. The default is 0.01.
-       
-      
-     
-
-     
-      cpu_index_tuple_cost (floating point)
-      
-       cpu_index_tuple_cost configuration parameter
-      
-      
-       
-        Sets the planner's estimate of the cost of processing
-        each index row during an index scan. This is measured as a
-        fraction of the cost of a sequential page fetch. The default
-        is 0.001.
-       
-      
-     
-    
-     
-      cpu_operator_cost (floating point)
-      
-       cpu_operator_cost configuration parameter
-      
-      
-       
-        Sets the planner's estimate of the cost of processing each
-        operator in a WHERE clause. This is measured as a fraction of
-        the cost of a sequential page fetch. The default is 0.0025.
-       
-      
-     
-
-     
-
-    
-     
-     Genetic Query Optimizer
-
-     
-
-     
-      
-       genetic query optimization
-      
-      
-       GEQO
-       genetic query optimization
-      
-      
-       geqo configuration parameter
-      
-      geqo (boolean)
-      
-       
-        Enables or disables genetic query optimization, which is an
-        algorithm that attempts to do query planning without
-        exhaustive searching. This is on by default. The
-        geqo_threshold variable provides a more
-        granular way to disable GEQO for certain classes of queries.
-       
-      
-     
-
-     
-      geqo_threshold (integer)
-      
-       geqo_threshold configuration parameter
-      
-      
-       
-        Use genetic query optimization to plan queries with at least
-        this many FROM items involved. (Note that an outer
-        JOIN construct counts as only one FROM
-        item.) The default is 12. For simpler queries it is usually best
-        to use the deterministic, exhaustive planner, but for queries with
-        many tables the deterministic planner takes too long.
-       
-      
-     
-
-     
-      geqo_effort
-      (integer)
-      
-       geqo_effort configuration parameter
-      
-      
-       
-        Controls the trade off between planning time and query plan
-        efficiency in GEQO. This variable must be an integer in the
-        range from 1 to 10. The default value is 5. Larger values
-        increase the time spent doing query planning, but also
-        increase the likelihood that an efficient query plan will be
-        chosen.
-       
-
-       
-        geqo_effort doesn't actually do anything
-        directly; it is only used to compute the default values for
-        the other variables that influence GEQO behavior (described
-        below). If you prefer, you can set the other parameters by
-        hand instead.
-       
-      
-     
-
-     
-      geqo_pool_size (integer)
-      
-       geqo_pool_size configuration parameter
-      
-      
-       
-        Controls the pool size used by GEQO. The pool size is the
-        number of individuals in the genetic population.  It must be
-        at least two, and useful values are typically 100 to 1000.  If
-        it is set to zero (the default setting) then a suitable
-        default is chosen based on geqo_effort and
-        the number of tables in the query.
-       
-      
-     
-
-     
-      geqo_generations (integer)
-      
-       geqo_generations configuration parameter
-      
-      
-       
-        Controls the number of generations used by GEQO.  Generations
-        specifies the number of iterations of the algorithm.  It must
-        be at least one, and useful values are in the same range as
-        the pool size.  If it is set to zero (the default setting)
-        then a suitable default is chosen based on
-        geqo_pool_size.
-       
-      
-     
-
-     
-      geqo_selection_bias (floating point)
-      
-       geqo_selection_bias configuration parameter
-      
-      
-       
-        Controls the selection bias used by GEQO. The selection bias
-        is the selective pressure within the population. Values can be
-        from 1.50 to 2.00; the latter is the default.
-       
-      
-     
-     
-     
-    
-     
-     Other Planner Options
-
-     
-
-     
-      default_statistics_target (integer)
-      
-       default_statistics_target configuration parameter
-      
-      
-       
-        Sets the default statistics target for table columns that have
-        not had a column-specific target set via ALTER TABLE
-        SET STATISTICS.  Larger values increase the time needed to
-        do ANALYZE, but may improve the quality of the
-        planner's estimates. The default is 10. For more information
-        on the use of statistics by the PostgreSQL
-        query planner, refer to .
-       
-      
-     
-
-     
-      constraint_exclusion (boolean)
-      
-       constraint exclusion
-      
-      
-       constraint_exclusion configuration parameter
-      
-      
-       
-        Enables or disables the query planner's use of table constraints to
-        limit table access.  The default is off.
-       
-
-       
-        When this parameter is on, the planner compares query
-        conditions with table CHECK constraints, and omits scanning tables
-        where the conditions contradict the constraints.  (Presently
-        this is done only for child tables of inheritance scans.)  For
-        example:
-
-
-CREATE TABLE parent(key integer, ...);
-CREATE TABLE child1000(check (key between 1000 and 1999)) INHERITS(parent);
-CREATE TABLE child2000(check (key between 2000 and 2999)) INHERITS(parent);
-...
-SELECT * FROM parent WHERE key = 2400;
-
-
-        With constraint exclusion enabled, this SELECT will not scan
-        child1000 at all.  This can improve performance when
-        inheritance is used to build partitioned tables.
-       
-
-       
-        Currently, constraint_exclusion defaults to
-        off, because it risks incorrect results if
-        query plans are cached --- if a table constraint is changed or dropped,
-        the previously generated plan might now be wrong, and there is no
-        built-in mechanism to force re-planning.  (This deficiency will
-        probably be addressed in a future
-        PostgreSQL release.)  Another reason
-        for keeping it off is that the constraint checks are relatively
-        expensive, and in many circumstances will yield no savings.
-        It is recommended to turn this on only if you are actually using
-        partitioned tables designed to take advantage of the feature.
-       
-      
-     
-
-     
-      from_collapse_limit (integer)
-      
-       from_collapse_limit configuration parameter
-      
-      
-       
-        The planner will merge sub-queries into upper queries if the
-        resulting FROM list would have no more than
-        this many items.  Smaller values reduce planning time but may
-        yield inferior query plans.  The default is 8.  It is usually
-        wise to keep this less than .
-       
-      
-     
-
-     
-      join_collapse_limit (integer)
-      
-       join_collapse_limit configuration parameter
-      
-      
-       
-        The planner will rewrite explicit inner JOIN
-        constructs into lists of FROM items whenever a
-        list of no more than this many items in total would
-        result. Prior to PostgreSQL 7.4, joins
-        specified via the JOIN construct would
-        never be reordered by the query planner. The query planner has
-        subsequently been improved so that inner joins written in this
-        form can be reordered; this configuration parameter controls
-        the extent to which this reordering is performed.
-        
-         
-          At present, the order of outer joins specified via the
-          JOIN construct is never adjusted by the query
-          planner; therefore, join_collapse_limit has no
-          effect on this behavior. The planner may be improved to
-          reorder some classes of outer joins in a future release of
-          PostgreSQL.
-         
-        
-       
-
-       
-        By default, this variable is set the same as
-        from_collapse_limit, which is appropriate
-        for most uses. Setting it to 1 prevents any reordering of
-        inner JOINs. Thus, the explicit join order
-        specified in the query will be the actual order in which the
-        relations are joined. The query planner does not always choose
-        the optimal join order; advanced users may elect to
-        temporarily set this variable to 1, and then specify the join
-        order they desire explicitly. Another consequence of setting
-        this variable to 1 is that the query planner will behave more
-        like the PostgreSQL 7.3 query
-        planner, which some users might find useful for backward
-        compatibility reasons.
-       
-
-       
-        Setting this variable to a value between 1 and
-        from_collapse_limit might be useful to
-        trade off planning time against the quality of the chosen plan
-        (higher values produce better plans).
-       
-      
-     
-     
-     
-    
-   
-
-   
-    Error Reporting and Logging
-
-    
-     server log
-    
-
-    
-     Where to log
-
-     
-      where to log
-     
-
-     
-
-     
-      log_destination (string)
-      
-       log_destination configuration parameter
-      
-      
-       
-        PostgreSQL supports several methods
-         for logging server messages, including
-         stderr and
-         syslog. On Windows, 
-         eventlog is also supported. Set this
-         option to a list of desired log destinations separated by
-         commas. The default is to log to stderr 
-         only.
-         This option can only be set at server start or in the
-         postgresql.conf configuration file.
-       
-      
-     
-
-     
-      redirect_stderr (boolean)
-      
-       redirect_stderr configuration parameter
-      
-      
-       
-         This option allows messages sent to stderr to be
-         captured and redirected into log files.
-         This option, in combination with logging to stderr,
-         is often more useful than
-         logging to syslog, since some types of messages
-         may not appear in syslog output (a common example
-         is dynamic-linker failure messages).
-         This option can only be set at server start.
-       
-      
-     
-
-     
-      log_directory (string)
-      
-       log_directory configuration parameter
-      
-      
-       
-        When redirect_stderr is enabled, this option
-        determines the directory in which log files will be created.
-        It may be specified as an absolute path, or relative to the
-        cluster data directory.
-        This option can only be set at server start or in the
-        postgresql.conf configuration file.
-       
-      
-     
-
-     
-      log_filename (string)
-      
-       log_filename configuration parameter
-      
-      
-       
-        When redirect_stderr is enabled, this option
-        sets the file names of the created log files.  The value
-        is treated as a strftime pattern,
-        so %-escapes
-        can be used to specify time-varying file names.
-        If no %-escapes are present,
-        PostgreSQL will
-        append the epoch of the new log file's open time.  For example,
-        if log_filename were server_log, then the
-        chosen file name would be server_log.1093827753
-        for a log starting at Sun Aug 29 19:02:33 2004 MST.
-        This option can only be set at server start or in the
-        postgresql.conf configuration file.
-       
-      
-     
-
-     
-      log_rotation_age (integer)
-      
-       log_rotation_age configuration parameter
-      
-      
-       
-        When redirect_stderr is enabled, this option
-        determines the maximum lifetime of an individual log file.
-        After this many minutes have elapsed, a new log file will
-        be created.  Set to zero to disable time-based creation of
-        new log files.
-        This option can only be set at server start or in the
-        postgresql.conf configuration file.
-       
-      
-     
-
-     
-      log_rotation_size (integer)
-      
-       log_rotation_size configuration parameter
-      
-      
-       
-        When redirect_stderr is enabled, this option
-        determines the maximum size of an individual log file.
-        After this many kilobytes have been emitted into a log file,
-        a new log file will be created.  Set to zero to disable size-based
-        creation of new log files.
-        This option can only be set at server start or in the
-        postgresql.conf configuration file.
-       
-      
-     
-
-     
-      log_truncate_on_rotation (boolean)
-      
-       log_truncate_on_rotation configuration parameter
-      
-      
-       
-        When redirect_stderr is enabled, this option will cause
-        PostgreSQL to truncate (overwrite),
-        rather than append to, any existing log file of the same name.
-        However, truncation will occur only when a new file is being opened
-        due to time-based rotation, not during server startup or size-based
-        rotation.  When off, pre-existing files will be appended to in
-        all cases.  For example, using this option in combination with
-        a log_filename like postgresql-%H.log
-        would result in generating twenty-four hourly log files and then
-        cyclically overwriting them.
-        This option can only be set at server start or in the
-        postgresql.conf configuration file.
-       
-       
-        Example:  To keep 7 days of logs, one log file per day named
-        server_log.Mon, server_log.Tue, 
-        etc, and automatically overwrite last week's log with this week's log,
-        set log_filename to server_log.%a, 
-        log_truncate_on_rotation to on, and 
-        log_rotation_age to 1440.
-       
-       
-        Example: To keep 24 hours of logs, one log file per hour, but 
-        also rotate sooner if the log file size exceeds 1GB, set 
-        log_filename to server_log.%H%M, 
-        log_truncate_on_rotation to on, 
-        log_rotation_age to 60, and 
-        log_rotation_size to 1000000.
-        Including %M in log_filename allows
-        any size-driven rotations that may occur to select a filename
-        different from the hour's initial filename.
-       
-      
-     
-
-     
-      syslog_facility (string)
-      
-       syslog_facility configuration parameter
-      
-      
-       
-        When logging to syslog is enabled, this option
-        determines the syslog
-        facility to be used.  You may choose
-        from LOCAL0, LOCAL1,
-        LOCAL2, LOCAL3, LOCAL4,
-        LOCAL5, LOCAL6, LOCAL7;
-        the default is LOCAL0. See also the
-        documentation of your system's
-        syslog daemon.
-        This option can only be set at server start.
-       
-      
-     
-     
-     
-      syslog_ident (string)
-      
-       syslog_identity configuration parameter
-      
-       
-        
-         When logging to syslog is enabled, this option
-         determines the program name used to identify
-         PostgreSQL messages in
-         syslog logs. The default is
-         postgres.
-          This option can only be set at server start.
-        
-       
-      
-      
-      
-    
-     
-     When To Log
-
-     
-
-     
-      client_min_messages (string)
-      
-       client_min_messages configuration parameter
-      
-      
-       
-        Controls which message levels are sent to the client.
-        Valid values are DEBUG5,
-        DEBUG4, DEBUG3, DEBUG2,
-        DEBUG1, LOG, NOTICE,
-        WARNING, and ERROR.  Each level
-        includes all the levels that follow it.  The later the level,
-        the fewer messages are sent.  The default is
-        NOTICE.  Note that LOG has a different
-        rank here than in log_min_messages.
-       
-      
-     
-
-     
-      log_min_messages (string)
-      
-       log_min_messages configuration parameter
-      
-      
-       
-        Controls which message levels are written to the server log.
-        Valid values are DEBUG5, DEBUG4,
-        DEBUG3, DEBUG2, DEBUG1,
-        INFO, NOTICE, WARNING,
-        ERROR, LOG, FATAL, and
-        PANIC.  Each level includes all the levels that
-        follow it.  The later the level, the fewer messages are sent
-        to the log.  The default is NOTICE.  Note that
-        LOG has a different rank here than in
-        client_min_messages.
-        Only superusers can change this setting.
-       
-      
-     
-
-     
-      log_error_verbosity (string)
-      
-       log_error_verbosity configuration parameter
-      
-      
-       
-        Controls the amount of detail written in the server log for each
-        message that is logged.  Valid values are TERSE,
-        DEFAULT, and VERBOSE, each adding more
-        fields to displayed messages.
-        Only superusers can change this setting.
-       
-      
-     
-
-     
-      log_min_error_statement (string)
-      
-       log_min_error_statement configuration parameter
-      
-      
-       
-        Controls whether or not the SQL statement that causes an error
-        condition will also be recorded in the server log. All SQL
-        statements that cause an error of the specified level or
-        higher are logged.  The default is
-        PANIC (effectively turning this feature
-        off for normal use). Valid values are DEBUG5,
-        DEBUG4, DEBUG3,
-        DEBUG2, DEBUG1,
-        INFO, NOTICE,
-        WARNING, ERROR,
-        FATAL, and PANIC.  For
-        example, if you set this to ERROR then all
-        SQL statements causing errors, fatal errors, or panics will be
-        logged. Enabling this option can be helpful in tracking down
-        the source of any errors that appear in the server log.
-        Only superusers can change this setting.
-       
-      
-     
-     
-     
-      log_min_duration_statement (integer)
-      
-       log_min_duration_statement configuration parameter
-      
-       
-        
-         Logs the statement and its duration on a single log line if its
-         duration is greater than or equal to the specified number of
-         milliseconds. Setting this to zero will print all statements
-         and their durations. Minus-one (the default) disables the
-         feature. For example, if you set it to 250
-         then all SQL statements that run 250ms or longer will be
-         logged. Enabling this option can be useful in tracking down
-         unoptimized queries in your applications. This setting is
-         independent of log_statement and
-         log_duration. Only superusers can change
-         this setting.
-        
-       
-      
-
-     
-      silent_mode (boolean)
-      
-       silent_mode configuration parameter
-      
-      
-       
-        Runs the server silently. If this option is set, the server
-        will automatically run in background and any controlling
-        terminals are disassociated (same effect as
-        postmaster's -S option).
-        The server's standard output and standard error are redirected
-        to /dev/null, so any messages sent to them will be lost.
-        Unless syslog logging is selected or
-        redirect_stderr is enabled, using this option
-        is discouraged because it makes it impossible to see error messages.
-       
-      
-     
-
-     
-
-       
-        Here is a list of the various message severity levels used in
-        these settings:
-        
-         
-          DEBUG[1-5]
-          
-           
-            Provides information for use by developers.
-           
-          
-         
-
-         
-          INFO
-          
-           
-            Provides information implicitly requested by the user,
-            e.g., during VACUUM VERBOSE.
-           
-          
-         
-
-         
-          NOTICE
-          
-           
-            Provides information that may be helpful to users, e.g.,
-            truncation of long identifiers and the creation of indexes as part
-            of primary keys.
-           
-          
-         
-
-         
-          WARNING
-          
-           
-            Provides warnings to the user, e.g., COMMIT
-            outside a transaction block.
-           
-          
-         
-
-         
-          ERROR
-          
-           
-            Reports an error that caused the current command to abort.
-           
-          
-         
-
-         
-          LOG
-          
-           
-            Reports information of interest to administrators, e.g.,
-            checkpoint activity.
-           
-          
-         
-
-         
-          FATAL
-          
-           
-            Reports an error that caused the current session to abort.
-           
-          
-         
-
-         
-          PANIC
-          
-           
-            Reports an error that caused all sessions to abort.
-           
-          
-         
-        
-       
-
-    
-     
-     What To Log
-
-     
-
-     
-      debug_print_parse (boolean)
-      debug_print_rewritten (boolean)
-      debug_print_plan (boolean)
-      debug_pretty_print (boolean)
-      
-       debug_print_parse configuration parameter
-      
-      
-       debug_print_rewritten configuration parameter
-      
-      
-       debug_print_plan configuration parameter
-      
-      
-       debug_pretty_print configuration parameter
-      
-      
-       
-        These options enable various debugging output to be emitted.
-        For each executed query, they print
-        the resulting parse tree, the query rewriter output, or the
-        execution plan.  debug_pretty_print indents
-        these displays to produce a more readable but much longer
-        output format.  client_min_messages or
-        log_min_messages must be
-        DEBUG1 or lower to actually send this output
-        to the client or the server log, respectively.
-        These options are off by default.
-       
-      
-     
-
-     
-      log_connections (boolean)
-      
-       log_connections configuration parameter
-      
-      
-       
-        This outputs a line to the server log detailing each successful
-        connection. This is off by default, although it is probably very
-        useful. This option can only be set at server start or in the
-        postgresql.conf configuration file.
-       
-      
-     
-
-     
-      log_disconnections (boolean)
-      
-       log_disconnections configuration parameter
-      
-      
-       
-        This outputs a line in the server log similar to
-        log_connections but at session termination,
-        and includes the duration of the session.  This is off by
-        default. This option can only be set at server start or in the
-        postgresql.conf configuration file.
-       
-      
-     
-
-
-     
-      log_duration (boolean)
-      
-       log_duration configuration parameter
-      
-      
-       
-        Causes the duration of every completed statement which satisfies
-        log_statement to be logged.  When using this option, 
-        if you are not using syslog, it is recommended 
-        that you log the PID or session ID using log_line_prefix 
-        so that you can link the statement to the 
-        duration using the process ID or session ID. The default is
-        off. Only superusers can change this setting.
-       
-      
-     
-     
-     
-      log_line_prefix (string)
-      
-       log_line_prefix configuration parameter
-      
-      
-       
-         This is a printf-style string that is output at the
-         beginning of each log line. The default is an empty string.
-         Each recognized escape is replaced as outlined 
-         below - anything else that looks like an escape is ignored. Other
-         characters are copied straight to the log line. Some escapes are
-         only recognised by session processes, and do not apply to
-         background processes such as the postmaster. Syslog
-         produces its own 
-         time stamp and process ID information, so you probably do not want to
-         use those escapes if you are using syslog.
-         This option can only be set at server start or in the
-         postgresql.conf configuration file.
-
-         
-          
-           
-            
-             Escape
-             Effect
-             Session only
-             
-            
-           
-            
-             %u
-             User name
-             yes
-            
-            
-             %d
-             Database name
-             yes
-            
-            
-             %r
-             Remote host name or IP address, and remote port
-             yes
-            
-            
-             %h
-             Remote Hostname or IP address
-             yes
-            
-            
-             %p
-             Process ID
-             no
-            
-            
-             %t
-             Time stamp (no milliseconds)
-             no
-            
-            
-             %m
-             Time stamp with milliseconds
-             no
-            
-            
-             %i
-             Command tag: This is the command that generated the log line.
-             yes
-            
-            
-             %c
-             Session ID: A unique identifier for each session.
-             It is 2 4-byte hexadecimal numbers (without leading zeros) 
-             separated by a dot. The numbers
-             are the session start time and the process ID, so this can also
-             be used as a space saving way of printing these items.
-             yes
-            
-            
-             %l
-             Number of the log line for each process, starting at 1
-             no
-            
-            
-             %s
-             Session start time stamp
-             yes
-            
-            
-             %x
-             Transaction ID
-             yes
-            
-            
-             %q
-             Does not produce any output, but tells non-session
-             processes to stop at this point in the string. Ignored by
-             session processes.
-             no
-            
-            
-             %%
-             Literal %
-             no
-            
-           
-          
-         
-       
-      
-     
-
-     
-      log_statement (string)
-      
-       log_statement configuration parameter
-      
-      
-       
-        Controls which SQL statements are logged. Valid values are
-        none, ddl, mod, and
-        all. ddl logs all data definition
-        commands like CREATE, ALTER, and
-        DROP commands. mod logs all
-        ddl statements, plus INSERT,
-        UPDATE, DELETE, TRUNCATE,
-        and COPY FROM. PREPARE and
-        EXPLAIN ANALYZE statements are also logged if their
-        contained command is of an appropriate type.
-       
-       
-        The default is none. Only superusers can change this
-        setting.
-       
-
-       
-        
-         The EXECUTE statement is not considered a
-         ddl or mod statement.  When it is logged, 
-         only the name of the prepared statement is reported, not the
-         actual prepared statement.
-        
-
-        
-         When a function is defined in the
-         PL/pgSQLserver-side language, any queries
-         executed by the function will only be logged the first time that the
-         function is invoked in a particular session. This is because
-         PL/pgSQL keeps a cache of the
-         query plans produced for the SQL statements in the function.
-        
-       
-      
-     
-
-     
-      log_hostname (boolean)
-      
-       log_hostname configuration parameter
-      
-      
-       
-        By default, connection log messages only show the IP address of the
-        connecting host. Turning on this option causes logging of the
-        host name as well.  Note that depending on your host name resolution
-        setup this might impose a non-negligible performance penalty. This
-        option can only be set at server start or in the
-        postgresql.conf file.
-       
-      
-     
-
-     
-    
-   
-
-   
-    Runtime Statistics
-
-    
-     Statistics Monitoring
-     
-
-     
-      log_statement_stats (boolean)
-      log_parser_stats (boolean)
-      log_planner_stats (boolean)
-      log_executor_stats (boolean)
-      
-       log_statement_stats configuration parameter
-      
-      
-       log_parser_stats configuration parameter
-      
-      
-       log_planner_stats configuration parameter
-      
-      
-       log_executor_stats configuration parameter
-      
-      
-       
-        For each query, write performance statistics of the respective
-        module to the server log. This is a crude profiling
-        instrument.  log_statement_stats reports total
-        statement statistics, while the others report per-module statistics.
-        log_statement_stats cannot be enabled together with
-        any of the per-module options.  All of these options are disabled by
-        default.   Only superusers can change these settings.
-       
-      
-     
-
-     
-
-    
-    
-     Query and Index Statistics Collector
-     
-
-     
-      stats_start_collector (boolean)
-      
-       stats_start_collector configuration parameter
-      
-      
-       
-        Controls whether the server should start the
-        statistics-collection subprocess.  This is on by default, but
-        may be turned off if you know you have no interest in
-        collecting statistics.  This option can only be set at server
-        start.
-       
-      
-     
-
-     
-      stats_command_string (boolean)
-      
-       stats_command_string configuration parameter
-      
-      
-       
-        Enables the collection of statistics on the currently
-        executing command of each session, along with the time at
-        which that command began execution. This option is off by
-        default. Note that even when enabled, this information is not
-        visible to all users, only to superusers and the user owning
-        the session being reported on; so it should not represent a
-        security risk. This data can be accessed via the
-        pg_stat_activity system view; refer
-        to  for more information.
-       
-      
-     
-
-     
-      stats_block_level (boolean)
-      
-       stats_block_level configuration parameter
-      
-      
-       
-        Enables the collection of block-level statistics on database
-        activity. This option is disabled by default. If this option
-        is enabled, the data that is produced can be accessed via the
-        pg_stat and
-        pg_statio family of system views;
-        refer to  for more information.
-       
-      
-     
-
-     
-      stats_row_level (boolean)
-      
-       stats_row_level configuration parameter
-      
-      
-       
-        Enables the collection of row-level statistics on database
-        activity. This option is disabled by default. If this option
-        is enabled, the data that is produced can be accessed via the
-        pg_stat and
-        pg_statio family of system views;
-        refer to  for more information.
-       
-      
-     
-
-     
-      stats_reset_on_server_start (boolean)
-      
-       stats_reset_on_server_start configuration parameter
-      
-      
-       
-        If on, collected statistics are zeroed out whenever the server
-        is restarted. If off, statistics are accumulated across server
-        restarts. The default is off. This option can only 
-        be set at server start.
-       
-      
-     
-
-     
-    
-   
-
-   
-    Automatic Vacuuming
-
-     
-      Beginning in PostgreSQL 8.1, there is an optional server
-      process called the autovacuum daemon, whose purpose is
-      to automate the issuance of periodic VACUUM and
-      ANALYZE commands.  When enabled, the autovacuum daemon
-      runs periodically and checks for tables that have had a large number
-      of updated or deleted tuples.  This check uses the row-level statistics
-      collection facility; therefore, the autovacuum daemon cannot be used
-      unless  and
-       are set TRUE.  Also, it's
-      important to allow a slot for the autovacuum process when choosing
-      the value of .
-     
-
-    
-
-     
-      autovacuum (boolean)
-      
-       autovacuum configuration parameter
-      
-      
-       
-        Controls whether the server should start the
-        autovacuum subprocess.  This is off by default.
-        This option can only be set at server start or in the
-        postgresql.conf file.
-       
-      
-     
-
-     
-      autovacuum_naptime (integer)
-      
-       autovacuum_naptime configuration parameter
-      
-      
-       
-        Specifies the delay between activity rounds for the autovacuum
-        subprocess.  In each round the subprocess examines one database
-        and issues VACUUM and ANALYZE commands
-        as needed for tables in that database.  The delay is measured
-        in seconds, and the default is 60.
-        This option can only be set at server start or in the
-        postgresql.conf file.
-       
-      
-     
-
-     
-      autovacuum_vacuum_threshold (integer)
-      
-       autovacuum_vacuum_threshold configuration parameter
-      
-      
-       
-        Specifies the minimum number of updated or deleted tuples needed
-        to trigger a VACUUM in any one table.
-        The default is 1000.
-        This option can only be set at server start or in the
-        postgresql.conf file.
-       
-      
-     
-
-     
-      autovacuum_analyze_threshold (integer)
-      
-       autovacuum_analyze_threshold configuration parameter
-      
-      
-       
-        Specifies the minimum number of inserted, updated or deleted tuples
-        needed to trigger an ANALYZE in any one table.
-        The default is 500.
-        This option can only be set at server start or in the
-        postgresql.conf file.
-       
-      
-     
-
-     
-      autovacuum_vacuum_scale_factor (floating point)
-      
-       autovacuum_vacuum_scale_factor configuration parameter
-      
-      
-       
-        Specifies a fraction of the table size to add to
-        autovacuum_vacuum_threshold
-        when deciding whether to trigger a VACUUM.
-        The default is 0.4.
-        This option can only be set at server start or in the
-        postgresql.conf file.
-       
-      
-     
-
-     
-      autovacuum_analyze_scale_factor (floating point)
-      
-       autovacuum_analyze_scale_factor configuration parameter
-      
-      
-       
-        Specifies a fraction of the table size to add to
-        autovacuum_analyze_threshold
-        when deciding whether to trigger an ANALYZE.
-        The default is 0.2.
-        This option can only be set at server start or in the
-        postgresql.conf file.
-       
-      
-     
-
-     
-      autovacuum_vacuum_cost_delay (integer)
-      
-       autovacuum_vacuum_cost_delay configuration parameter
-      
-      
-       
-        Specifies the cost delay value that will be used in automatic
-        VACUUM operations.  If -1 is specified (which is the
-        default), the regular
-         value will be used.
-        This setting can be overridden for individual tables by entries in
-        pg_autovacuum.
-       
-      
-     
-
-     
-      autovacuum_vacuum_cost_limit (integer)
-      
-       autovacuum_vacuum_cost_limit configuration parameter
-      
-      
-       
-        Specifies the cost limit value that will be used in automatic
-        VACUUM operations.  If -1 is specified (which is the
-        default), the regular
-         value will be used.
-        This setting can be overridden for individual tables by entries in
-        pg_autovacuum.
-       
-      
-     
-
-    
-   
-
-   
-    Client Connection Defaults
-
-    
-     Statement Behavior
-     
-
-     
-      search_path (string)
-      
-       search_path configuration parameter
-      
-      pathfor schemas
-      
-       
-        This variable specifies the order in which schemas are searched
-        when an object (table, data type, function, etc.) is referenced by a
-        simple name with no schema component.  When there are objects of
-        identical names in different schemas, the one found first
-        in the search path is used.  An object that is not in any of the
-        schemas in the search path can only be referenced by specifying
-        its containing schema with a qualified (dotted) name.
-       
-
-       
-        The value for search_path has to be a comma-separated
-        list of schema names.  If one of the list items is
-        the special value $user, then the schema
-        having the name returned by SESSION_USER is substituted, if there
-        is such a schema.  (If not, $user is ignored.)
-       
-
-       
-        The system catalog schema, pg_catalog, is always
-        searched, whether it is mentioned in the path or not.  If it is
-        mentioned in the path then it will be searched in the specified
-        order.  If pg_catalog is not in the path then it will
-        be searched before searching any of the path items.
-        It should also be noted that the temporary-table schema,
-        pg_temp_nnn, is implicitly searched before any of
-        these.
-       
-
-       
-        When objects are created without specifying a particular target
-        schema, they will be placed in the first schema listed
-        in the search path.  An error is reported if the search path is
-        empty.
-       
-
-       
-        The default value for this parameter is
-        '$user, public' (where the second part will be
-        ignored if there is no schema named public).
-        This supports shared use of a database (where no users
-        have private schemas, and all share use of public),
-        private per-user schemas, and combinations of these.  Other
-        effects can be obtained by altering the default search path
-        setting, either globally or per-user.
-       
-
-       
-        The current effective value of the search path can be examined
-        via the SQL function
-        current_schemas().  This is not quite the same as
-        examining the value of search_path, since
-        current_schemas() shows how the requests
-        appearing in search_path were resolved.
-       
-
-       
-        For more information on schema handling, see .
-       
-      
-     
-
-     
-      default_tablespace (string)
-      
-       default_tablespace configuration parameter
-      
-      tablespacedefault
-      
-       
-        This variable specifies the default tablespace in which to create
-        objects (tables and indexes) when a CREATE command does
-        not explicitly specify a tablespace.
-       
-
-       
-        The value is either the name of a tablespace, or an empty string
-        to specify using the default tablespace of the current database.
-        If the value does not match the name of any existing tablespace,
-        PostgreSQL will automatically use the default
-        tablespace of the current database.
-       
-
-       
-        For more information on tablespaces,
-        see .
-       
-      
-     
-
-     
-      check_function_bodies (boolean)
-      
-       check_function_bodies configuration parameter
-      
-      
-       
-        This parameter is normally on. When set to off, it
-        disables validation of the function body string during 
-        linkend="sql-createfunction"
-        endterm="sql-createfunction-title">. Disabling validation is
-        occasionally useful to avoid problems such as forward references
-        when restoring function definitions from a dump.
-       
-      
-     
-
-     
-      
-       transaction isolation level
-      
-      
-       default_transaction_isolation configuration parameter
-      
-      default_transaction_isolation (string)
-      
-       
-        Each SQL transaction has an isolation level, which can be
-        either read uncommitted, read
-        committed, repeatable read, or
-        serializable.  This parameter controls the
-        default isolation level of each new transaction. The default
-        is read committed.
-       
-
-       
-        Consult  and 
-        linkend="sql-set-transaction"
-        endterm="sql-set-transaction-title"> for more information.
-       
-      
-     
-
-     
-      
-       read-only transaction
-      
-      
-       default_transaction_read_only configuration parameter
-      
-
-      default_transaction_read_only (boolean)
-      
-       
-        A read-only SQL transaction cannot alter non-temporary tables.
-        This parameter controls the default read-only status of each new
-        transaction. The default is off (read/write).
-       
-
-       
-        Consult 
-        endterm="sql-set-transaction-title"> for more information.
-       
-      
-     
-     
-     
-      statement_timeout (integer)
-      
-       statement_timeout configuration parameter
-      
-      
-       
-        Abort any statement that takes over the specified number of
-        milliseconds.  A value of zero (the default) turns off the limitation.
-       
-      
-     
-     
-     
-    
-     
-     Locale and Formatting
-
-     
-
-     
-      DateStyle (string)
-      
-       DateStyle configuration parameter
-      
-      
-       
-        Sets the display format for date and time values, as well as the
-        rules for interpreting ambiguous date input values. For
-        historical reasons, this variable contains two independent
-        components: the output format specification (ISO,
-        Postgres, SQL, or German)
-        and the input/output specification for year/month/day ordering
-        (DMY, MDY, or YMD). These
-        can be set separately or together. The keywords Euro
-        and European are synonyms for DMY; the
-        keywords US, NonEuro, and
-        NonEuropean are synonyms for MDY. See
-         for more information. The
-        default is ISO, MDY.
-       
-      
-     
-
-     
-      timezone (string)
-      
-       timezone configuration parameter
-      
-      time zone
-      
-       
-        Sets the time zone for displaying and interpreting time
-        stamps.  The default is 'unknown', which means to use whatever 
-        the system environment specifies as the time zone.  See 
-        linkend="datatype-datetime"> for more information.
-       
-      
-     
-
-     
-      australian_timezones (boolean)
-      
-       australian_timezones configuration parameter
-      
-      time zoneAustralian
-      
-       
-        If set to on, ACST,
-        CST, EST, and
-        SAT are interpreted as Australian time
-        zones rather than as North/South American time zones and
-        Saturday. The default is off.
-       
-      
-     
-
-     
-      
-       significant digits
-      
-      
-       floating-point
-       display
-      
-      
-       extra_float_digits configuration parameter
-      
-
-      extra_float_digits (integer)
-      
-       
-        This parameter adjusts the number of digits displayed for
-        floating-point values, including float4, float8,
-        and geometric data types.  The parameter value is added to the
-        standard number of digits (FLT_DIG or DBL_DIG
-        as appropriate).  The value can be set as high as 2, to include
-        partially-significant digits; this is especially useful for dumping
-        float data that needs to be restored exactly.  Or it can be set
-        negative to suppress unwanted digits.
-       
-      
-     
-
-     
-      client_encoding (string)
-      
-       client_encoding configuration parameter
-      
-      character set
-      
-       
-        Sets the client-side encoding (character set).
-        The default is to use the database encoding.
-       
-      
-     
-
-     
-      lc_messages (string)
-      
-       lc_messages configuration parameter
-      
-      
-       
-        Sets the language in which messages are displayed.  Acceptable
-        values are system-dependent; see  for
-        more information.  If this variable is set to the empty string
-        (which is the default) then the value is inherited from the
-        execution environment of the server in a system-dependent way.
-       
-
-       
-        On some systems, this locale category does not exist.  Setting
-        this variable will still work, but there will be no effect.
-        Also, there is a chance that no translated messages for the
-        desired language exist.  In that case you will continue to see
-        the English messages.
-       
-      
-     
-
-     
-      lc_monetary (string)
-      
-       lc_monetary configuration parameter
-      
-      
-       
-        Sets the locale to use for formatting monetary amounts, for
-        example with the to_char family of
-        functions.  Acceptable values are system-dependent; see 
-        linkend="locale"> for more information.  If this variable is
-        set to the empty string (which is the default) then the value
-        is inherited from the execution environment of the server in a
-        system-dependent way.
-       
-      
-     
-
-     
-      lc_numeric (string)
-      
-       lc_numeric configuration parameter
-      
-      
-       
-        Sets the locale to use for formatting numbers, for example
-        with the to_char family of
-        functions. Acceptable values are system-dependent; see 
-        linkend="locale"> for more information.  If this variable is
-        set to the empty string (which is the default) then the value
-        is inherited from the execution environment of the server in a
-        system-dependent way.
-       
-      
-     
-
-     
-      lc_time (string)
-      
-       lc_time configuration parameter
-      
-      
-       
-        Sets the locale to use for formatting date and time values.
-        (Currently, this setting does nothing, but it may in the
-        future.)  Acceptable values are system-dependent; see 
-        linkend="locale"> for more information.  If this variable is
-        set to the empty string (which is the default) then the value
-        is inherited from the execution environment of the server in a
-        system-dependent way.
-       
-      
-     
-
-     
-
-    
-     
-     Other Defaults
-
-     
-
-     
-      explain_pretty_print (boolean)
-      
-       explain_pretty_print configuration parameter
-      
-      
-       
-        Determines whether EXPLAIN VERBOSE uses the
-        indented or non-indented format for displaying detailed
-        query-tree dumps. The default is on.
-       
-      
-     
-
-     
-      dynamic_library_path (string)
-      
-       dynamic_library_path configuration parameter
-      
-      dynamic loading
-      
-       
-        If a dynamically loadable module needs to be opened and the
-        file name specified in the CREATE FUNCTION or
-        LOAD command
-        does not have a directory component (i.e. the
-        name does not contain a slash), the system will search this
-        path for the required file.
-       
-
-       
-        The value for dynamic_library_path has to be a
-        list of absolute directory paths separated by colons (or semi-colons
-        on Windows).  If a list element starts
-        with the special string $libdir, the
-        compiled-in PostgreSQL package
-        library directory is substituted for $libdir. This
-        is where the modules provided by the standard
-        PostgreSQL distribution are installed.
-        (Use pg_config --pkglibdir to find out the name of
-        this directory.) For example:
-
-dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
-
-        or, in a Windows environment:
-
-dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
-
-       
-
-       
-        The default value for this parameter is
-        '$libdir'. If the value is set to an empty
-        string, the automatic path search is turned off.
-       
-
-       
-        This parameter can be changed at run time by superusers, but a
-        setting done that way will only persist until the end of the
-        client connection, so this method should be reserved for
-        development purposes. The recommended way to set this parameter
-        is in the postgresql.conf configuration
-        file.
-       
-      
-     
-
-     
-    
-   
-
-   
-    Lock Management
-
-     
-
-     
-      
-       deadlock
-       timeout during
-      
-      
-       timeout
-       deadlock
-      
-      
-       deadlock_timeout configuration parameter
-      
-
-      deadlock_timeout (integer)
-      
-       
-        This is the amount of time, in milliseconds, to wait on a lock
-        before checking to see if there is a deadlock condition. The
-        check for deadlock is relatively slow, so the server doesn't run
-        it every time it waits for a lock. We (optimistically?) assume
-        that deadlocks are not common in production applications and
-        just wait on the lock for a while before starting the check for a
-        deadlock. Increasing this value reduces the amount of time
-        wasted in needless deadlock checks, but slows down reporting of
-        real deadlock errors. The default is 1000 (i.e., one second),
-        which is probably about the smallest value you would want in
-        practice. On a heavily loaded server you might want to raise it.
-        Ideally the setting should exceed your typical transaction time,
-        so as to improve the odds that a lock will be released before
-        the waiter decides to check for deadlock.
-       
-      
-     
-
-     
-      max_locks_per_transaction (integer)
-      
-       max_locks_per_transaction configuration parameter
-      
-      
-       
-        The shared lock table is created with room to describe locks on
-        max_locks_per_transaction *
-        ( +
-        ) objects;
-        hence, no more than this many distinct objects can
-        be locked at any one time. (Thus, this parameter's name may be
-        confusing: it is not a hard limit on the number of locks taken
-        by any one transaction, but rather a maximum average value.)
-        The default, 64, has historically
-        proven sufficient, but you might need to raise this value if you
-        have clients that touch many different tables in a single
-        transaction. This option can only be set at server start.
-       
-
-       
-        Increasing this parameter may cause PostgreSQL
-        to request more System V shared
-        memory than your operating system's default configuration
-        allows. See  for information on how to
-        adjust those parameters, if necessary.
-       
-      
-     
-
-     
-   
-
-   
-    Version and Platform Compatibility
-
-    
-     Previous PostgreSQL Versions
-     
-
-     
-      add_missing_from (boolean)
-      FROMmissing
-      
-       add_missing_from configuration parameter
-      
-      
-       
-        When on, tables that are referenced by a query will be
-        automatically added to the FROM clause if not
-        already present. This behavior does not comply with the SQL
-        standard and many people dislike it because it can mask mistakes
-        (such as referencing a table where you should have referenced
-        its alias). The default is off. This variable can be
-        enabled for compatibility with releases of
-        PostgreSQL prior to 8.1, where this behavior was
-        allowed by default.
-       
-
-       
-        Note that even when this variable is enabled, a warning
-        message will be emitted for each implicit FROM
-        entry referenced by a query. Users are encouraged to update
-        their applications to not rely on this behavior, by adding all
-        tables referenced by a query to the query's FROM
-        clause (or its USING clause in the case of
-        DELETE).
-       
-      
-     
-
-     
-      regex_flavor (string)
-      regular expressions
-      
-       regex_flavor configuration parameter
-      
-      
-       
-        The regular expression flavor can be set to
-        advanced, extended, or basic.
-        The default is advanced.  The extended
-        setting may be useful for exact backwards compatibility with
-        pre-7.4 releases of PostgreSQL.  See
-         for details.
-       
-      
-     
-
-     
-      sql_inheritance (boolean)
-      
-       sql_inheritance configuration parameter
-      
-      inheritance
-      
-       
-        This controls the inheritance semantics, in particular whether
-        subtables are included by various commands by default. They were
-        not included in versions prior to 7.1. If you need the old
-        behavior you can set this variable to off, but in
-        the long run you are encouraged to change your applications to
-        use the ONLY key word to exclude subtables.
-        See  for more information about
-        inheritance.
-       
-      
-     
-
-     
-      default_with_oids (boolean)
-      
-       default_with_oids configuration parameter
-      
-      
-       
-        This controls whether CREATE TABLE and
-        CREATE TABLE AS include an OID column in
-        newly-created tables, if neither WITH OIDS
-        nor WITHOUT OIDS is specified. It also
-        determines whether OIDs will be included in tables created by
-        SELECT INTO. In PostgreSQL
-        8.1 default_with_oids is disabled by default; in
-        prior versions of PostgreSQL, it was on by default.
-       
-
-       
-        The use of OIDs in user tables is considered deprecated, so
-        most installations should leave this variable disabled.
-        Applications that require OIDs for a particular table should
-        specify WITH OIDS when creating the
-        table. This variable can be enabled for compatibility with old
-        applications that do not follow this behavior.
-       
-      
-     
-
-     
-      escape_string_warning (boolean)
-      stringsescape
-      
-       escape_string_warning configuration parameter
-      
-      
-       
-        When on, a warning is issued if a backslash (\)
-        appears in an ordinary string literal ('...'
-        syntax). The default is off.
-       
-       
-        Escape string syntax (E'...') should be used for
-        escapes, because in future versions of
-        PostgreSQL ordinary strings will have
-        the standard-conforming behavior of treating backslashes
-        literally.
-       
-      
-     
-
-     
-    
-    
-     Platform and Client Compatibility
-     
-
-     
-      transform_null_equals (boolean)
-      IS NULL
-      
-       transform_null_equals configuration parameter
-      
-      
-       
-        When on, expressions of the form expr =
-        NULL (or NULL =
-        expr) are treated as
-        expr IS NULL, that is, they
-        return true if expr evaluates to the null value,
-        and false otherwise. The correct SQL-spec-compliant behavior of
-        expr = NULL is to always
-        return null (unknown). Therefore this option defaults to
-        off.
-       
-
-       
-        However, filtered forms in Microsoft
-        Access generate queries that appear to use
-        expr = NULL to test for
-        null values, so if you use that interface to access the database you
-        might want to turn this option on.  Since expressions of the
-        form expr = NULL always
-        return the null value (using the correct interpretation) they are not
-        very useful and do not appear often in normal applications, so
-        this option does little harm in practice.  But new users are
-        frequently confused about the semantics of expressions
-        involving null values, so this option is not on by default.
-       
-
-       
-        Note that this option only affects the exact form = NULL,
-        not other comparison operators or other expressions
-        that are computationally equivalent to some expression
-        involving the equals operator (such as IN).
-        Thus, this option is not a general fix for bad programming.
-       
-
-       
-        Refer to  for related information.
-       
-      
-     
-
-     
-    
-   
-
-   
-    Preset Options
-
-    
-     The following parameters are read-only, and are determined
-     when PostgreSQL is compiled or when it is
-     installed. As such, they have been excluded from the sample
-     postgresql.conf file.  These options report
-     various aspects of PostgreSQL behavior
-     that may be of interest to certain applications, particularly
-     administrative front-ends.
-    
-
-    
-
-     
-      block_size (integer)
-      
-       block_size configuration parameter
-      
-      
-       
-        Reports the size of a disk block.  It is determined by the value
-        of BLCKSZ when building the server. The default
-        value is 8192 bytes.  The meaning of some configuration
-        variables (such as ) is
-        influenced by block_size. See 
-        linkend="runtime-config-resource"> for information.
-       
-      
-     
-
-     
-      integer_datetimes (boolean)
-      
-       integer_datetimes configuration parameter
-      
-      
-       
-        Reports whether PostgreSQL was built
-        with support for 64-bit-integer dates and times.  It is set by
-        configuring with --enable-integer-datetimes
-        when building PostgreSQL.  The
-        default value is off.
-       
-      
-     
-
-     
-      lc_collate (string)
-      
-       lc_collate configuration parameter
-      
-      
-       
-        Reports the locale in which sorting of textual data is done.
-        See  for more information.
-        The value is determined when the database cluster is initialized.
-       
-      
-     
-
-     
-      lc_ctype (string)
-      
-       lc_ctype configuration parameter
-      
-      
-       
-        Reports the locale that determines character classifications.
-        See  for more information.
-        The value is determined when the database cluster is initialized.
-        Ordinarily this will be the same as lc_collate,
-        but for special applications it might be set differently.
-       
-      
-     
-
-     
-      max_function_args (integer)
-      
-       max_function_args configuration parameter
-      
-      
-       
-        Reports the maximum number of function arguments. It is determined by
-        the value of FUNC_MAX_ARGS when building the server. The
-        default value is 100.
-       
-      
-     
-
-     
-      max_identifier_length (integer)
-      
-       max_identifier_length configuration parameter
-      
-      
-       
-        Reports the maximum identifier length. It is determined as one
-        less than the value of NAMEDATALEN when building
-        the server. The default value of NAMEDATALEN is
-        64; therefore the default
-        max_identifier_length is 63.
-       
-      
-     
-
-     
-      max_index_keys (integer)
-      
-       max_index_keys configuration parameter
-      
-      
-       
-        Reports the maximum number of index keys. It is determined by
-        the value of INDEX_MAX_KEYS when building the server. The
-        default value is 32.
-       
-      
-     
-
-     
-      server_encoding (string)
-      
-       server_encoding configuration parameter
-      
-      character set
-      
-       
-        Reports the database encoding (character set).
-        It is determined when the database is created.  Ordinarily,
-        clients need only be concerned with the value of 
-        linkend="guc-client-encoding">.
-       
-      
-     
-
-     
-      server_version (string)
-      
-       server_version configuration parameter
-      
-      
-       
-        Reports the version number of the server. It is determined by the
-        value of PG_VERSION when building the server.
-       
-      
-     
-
-     
-      standard_conforming_strings (boolean)
-      stringsescape
-      
-       standard_conforming_strings configuration parameter
-      
-      
-       
-        Reports whether ordinary string literals
-        ('...') treat backslashes literally, as specified in
-        the SQL standard.  The value is currently always off,
-        indicating that backslashes are treated as escapes.  It is planned
-        that this will change to on in a future
-        PostgreSQL release when string literal
-        syntax changes to meet the standard.  Applications may check this
-        parameter to determine how string literals will be processed.
-        The presence of this parameter can also be taken as an indication
-        that the escape string syntax (E'...') is supported.
-       
-      
-     
-
-    
-   
-
-   
-    Customized Options
-
-    
-     This feature was designed to allow options not normally known to
-     PostgreSQL to be added by add-on modules
-     (such as procedural languages).  This allows add-on modules to be
-     configured in the standard ways.
-    
-
-    
-
-     
-      custom_variable_classes (string)
-      
-       custom_variable_classes configuration parameter
-      
-      
-       
-        This variable specifies one or several class names to be used for
-        custom variables, in the form of a comma-separated list. A custom
-        variable is a variable not normally known
-        to PostgreSQL proper but used by some
-        add-on module.  Such variables must have names consisting of a class
-        name, a dot, and a variable name.  custom_variable_classes
-        specifies all the class names in use in a particular installation.
-        This option can only be set at server start or in the
-        postgresql.conf configuration file.
-       
-
-      
-     
-    
-
-    
-     The difficulty with setting custom variables in
-     postgresql.conf is that the file must be read before add-on
-     modules have been loaded, and so custom variables would ordinarily be
-     rejected as unknown.  When custom_variable_classes is set,
-     the server will accept definitions of arbitrary variables within each
-     specified class.  These variables will be treated as placeholders and
-     will have no function until the module that defines them is loaded. When a
-     module for a specific class is loaded, it will add the proper variable
-     definitions for its class name, convert any placeholder
-     values according to those definitions, and issue warnings for any
-     placeholders of its class that remain (which presumably would be
-     misspelled configuration variables).
-    
-
-    
-     Here is an example of what postgresql.conf might contain
-     when using custom variables:
-
-
-custom_variable_classes = 'plr,plperl'
-plr.path = '/usr/lib/R'
-plperl.use_strict = true
-plruby.use_strict = true        # generates error: unknown class name
-
-    
-   
-
-   
-    Developer Options
-
-    
-     The following options are intended for work on the
-     PostgreSQL source, and in some cases
-     to assist with recovery of severely damaged databases.  There
-     should be no reason to use them in a production database setup.
-     As such, they have been excluded from the sample
-     postgresql.conf file.  Note that many of these
-     options require special source compilation flags to work at all.
-    
-
-    
-     
-      debug_assertions (boolean)
-      
-       debug_assertions configuration parameter
-      
-      
-       
-        Turns on various assertion checks. This is a debugging aid. If
-        you are experiencing strange problems or crashes you might want
-        to turn this on, as it might expose programming mistakes. To use
-        this option, the macro USE_ASSERT_CHECKING
-        must be defined when PostgreSQL is
-        built (accomplished by the configure option
-        --enable-cassert). Note that
-        debug_assertions defaults to on
-        if PostgreSQL has been built with
-        assertions enabled.
-       
-      
-     
-
-     
-      pre_auth_delay (integer)
-      
-       pre_auth_delay configuration parameter
-      
-      
-       
-        If nonzero, a delay of this many seconds occurs just after a new
-        server process is forked, before it conducts the authentication
-        process.  This is intended to give an opportunity to attach to the
-        server process with a debugger to trace down misbehavior in
-        authentication.
-       
-      
-     
-
-     
-      trace_notify (boolean)
-      
-       trace_notify configuration parameter
-      
-      
-       
-        Generates a great amount of debugging output for the
-        LISTEN and NOTIFY
-        commands.   or
-         must be
-        DEBUG1 or lower to send this output to the
-        client or server log, respectively.
-       
-      
-     
-
-     
-      trace_locks (boolean)
-      trace_lwlocks (boolean)
-      trace_userlocks (boolean)
-      trace_lock_oidmin (boolean)
-      trace_lock_table (boolean)
-      debug_deadlocks (boolean)
-      log_btree_build_stats (boolean)
-      
-       
-        Various other code tracing and debugging options.
-       
-      
-     
-
-     
-      wal_debug (boolean)
-      
-       wal_debug configuration parameter
-      
-      
-       
-        If on, emit WAL-related debugging output. This option is
-        only available if the WAL_DEBUG macro was
-        defined when PostgreSQL was
-        compiled.
-       
-      
-     
-
-    
-      zero_damaged_pages (boolean)
-      
-       zero_damaged_pages configuration parameter
-      
-      
-       
-        Detection of a damaged page header normally causes
-        PostgreSQL to report an error, aborting the current
-        command.  Setting zero_damaged_pages to on causes
-        the system to instead report a warning, zero out the damaged page,
-        and continue processing.  This behavior will destroy data,
-        namely all the rows on the damaged page.  But it allows you to get
-        past the error and retrieve rows from any undamaged pages that may
-        be present in the table.  So it is useful for recovering data if
-        corruption has occurred due to hardware or software error.  You should
-        generally not set this on until you have given up hope of recovering
-        data from the damaged page(s) of a table.  The
-        default setting is off, and it can only be changed
-        by a superuser.
-       
-      
-     
-   
-  
-  
-   Short Options
-
-   
-    For convenience there are also single letter command-line option switches
-    available for some parameters. They are described in 
-    linkend="runtime-config-short-table">.
-   
-
-    
-     Short option key
-     
-      
-       
-        Short option
-        Equivalent
-       
-      
-
-      
-       
-        -B x
-        shared_buffers = x
-       
-       
-        -d x
-        log_min_messages = DEBUGx
-       
-       
-        -F
-        fsync = off
-       
-       
-        -h x
-        listen_addresses = x
-       
-       
-        -i
-        listen_addresses = '*'
-       
-       
-        -k x
-        unix_socket_directory = x
-       
-       
-        -l
-        ssl = on
-       
-       
-        -N x
-        max_connections = x
-       
-       
-        -p x
-        port = x
-       
-
-       
-        
-          -fb, -fh, -fi,
-          -fm, -fn,
-          -fs, -ft
-          id="fn.runtime-config-short">
-           
-            For historical reasons, these options must be passed to
-            the individual server process via the -o
-            postmaster option, for example,
-
-$ postmaster -o '-S 1024 -s'
-
-            or via PGOPTIONS from the client side, as
-            explained above.
-           
-          
-         
-         
-          enable_bitmapscan = off,
-          enable_hashjoin = off,
-          enable_indexscan = off,
-          enable_mergejoin = off,
-          enable_nestloop = off,
-          enable_seqscan = off,
-          enable_tidscan = off
-         
-       
-
-       
-        -s
-        log_statement_stats = on
-       
-
-       
-        -S x
-        
-        work_mem = x
-       
-
-       
-        -tpa, -tpl, -te
-        log_parser_stats = on,
-        log_planner_stats = on, 
-        log_executor_stats = on
-       
-      
-     
-    
-
-  
- 
-
-
  
   Managing Kernel Resources
 




This is the main PostgreSQL git repository.
RSS
Atom



window.onload = function () {
	var tz_cookie = { name: 'gitweb_tz', expires: 14, path: '/' };
	onloadTZSetup('local', tz_cookie, 'datetime');
};