runtime.sgml

PostgreSQL7.4.6 for Linux

      </listitem>
     </varlistentry>

     </variablelist>

    </sect3>
     <sect3 id="runtime-config-query-geqo">
     <title>Genetic Query Optimizer</title>

     <variablelist>

     <varlistentry>
      <indexterm>
       <primary>genetic query optimization</primary>
      </indexterm>
      <indexterm>
       <primary>GEQO</primary>
       <see>genetic query optimization</see>
      </indexterm>
      <term><varname>geqo</varname> (<type>boolean</type>)</term>
      <listitem>
       <para>
        Enables or disables genetic query optimization, which is an
        algorithm that attempts to do query planning without exhaustive
        searching. This is on by default. See also the various other
        <varname>geqo_</varname> settings.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><varname>geqo_threshold</varname> (<type>integer</type>)</term>
      <listitem>
       <para>
        Use genetic query optimization to plan queries with at least
        this many <literal>FROM</> items involved. (Note that an outer
        <literal>JOIN</> construct counts as only one <literal>FROM</>
        item.) The default is 11. 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.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><varname>geqo_effort</varname> (<type>integer</type>)</term>
      <term><varname>geqo_generations</varname> (<type>integer</type>)</term>
      <term><varname>geqo_pool_size</varname> (<type>integer</type>)</term>
      <term><varname>geqo_selection_bias</varname> (<type>floating point</type>)</term>
      <listitem>
       <para>
        Various tuning parameters for the genetic query optimization
        algorithm: The pool size is the number of individuals in one
        population. Valid values are between 128 and 1024. If it is set
        to 0 (the default) a pool size of 2^(QS+1), where QS is the
        number of <literal>FROM</> items in the query, is taken. The effort is used
        to calculate a default for generations. Valid values are between
        1 and 80, 40 being the default. Generations specifies the number
        of iterations in the algorithm. The number must be a positive
        integer. If 0 is specified then <literal>Effort *
        Log2(PoolSize)</literal> is used. The run time of the algorithm
        is roughly proportional to the sum of pool size and generations.
        The selection bias is the selective pressure within the
        population. Values can be from 1.50 to 2.00; the latter is the
        default.
       </para>
      </listitem>
     </varlistentry>
     
     </variablelist>
    </sect3>
     <sect3 id="runtime-config-query-other">
     <title>Other Planner Options</title>

     <variablelist>

     <varlistentry>
      <term><varname>default_statistics_target</varname> (<type>integer</type>)</term>
      <listitem>
       <para>
        Sets the default statistics target for table columns that have not
        had a column-specific target set via <command>ALTER TABLE SET
        STATISTICS</>.  Larger values increase the time needed to do
        <command>ANALYZE</>, but may improve the quality of the planner's
        estimates. The default is 10.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><varname>from_collapse_limit</varname> (<type>integer</type>)</term>
      <listitem>
       <para>
        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
        <varname>geqo_threshold</varname>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><varname>join_collapse_limit</varname> (<type>integer</type>)</term>
      <listitem>
       <para>
        The planner will flatten explicit inner <literal>JOIN</> constructs
        into lists of <literal>FROM</> items whenever a list of no more than
        this many items would result.  Usually this is set the same as
        <varname>from_collapse_limit</>.  Setting it to 1 prevents any
        flattening of inner <literal>JOIN</>s, allowing explicit
        <literal>JOIN</> syntax to be used to control the join order.
        Intermediate values might be useful to trade off planning time
        against quality of plan.
       </para>
      </listitem>
     </varlistentry>
     
     </variablelist>
    </sect3>
   </sect2>

   <sect2 id="runtime-config-logging">
    <title>Error Reporting and Logging</title>

    <indexterm zone="runtime-config-logging">
     <primary>server log</primary>
    </indexterm>

    <sect3 id="runtime-config-logging-syslog">
     <title>Syslog</title>

     <indexterm zone="runtime-config-logging-syslog">
      <primary>syslog</primary>
     </indexterm>

     <variablelist>

     <varlistentry>
      <term><varname>syslog</varname> (<type>integer</type>)</term>
      <listitem>
       <para>
        <productname>PostgreSQL</productname> allows the use of
        <systemitem>syslog</systemitem> for logging. If this option is
        set to 1, messages go both to <systemitem>syslog</> and the
        standard output. A setting of 2 sends output only to
        <systemitem>syslog</>. (Some messages will still go to the
        standard output/error.) The default is 0, which means
        <systemitem>syslog</> is off. This option must be set at server
        start.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><varname>syslog_facility</varname> (<type>string</type>)</term>
       <listitem>
        <para>
          This option determines the <application>syslog</application>
          <quote>facility</quote> to be used when logging via
          <application>syslog</application> is enabled. You may choose
          from <literal>LOCAL0</>, <literal>LOCAL1</>,
          <literal>LOCAL2</>, <literal>LOCAL3</>, <literal>LOCAL4</>,
          <literal>LOCAL5</>, <literal>LOCAL6</>, <literal>LOCAL7</>;
          the default is <literal>LOCAL0</>. See also the
          documentation of your system's
          <application>syslog</application>.
        </para>
       </listitem>
     </varlistentry>
     
     <varlistentry>
      <term><varname>syslog_ident</varname> (<type>string</type>)</term>
       <listitem>
        <para>
         If logging to <application>syslog</> is enabled, this option
         determines the program name used to identify
         <productname>PostgreSQL</productname> messages in
         <application>syslog</application> log messages. The default is
         <literal>postgres</literal>.
        </para>
       </listitem>
      </varlistentry>
      
      </variablelist>
    </sect3>
     <sect3 id="runtime-config-logging-when">
     <title>When To Log</title>

     <variablelist>

     <varlistentry>
      <term><varname>client_min_messages</varname> (<type>string</type>)</term>
      <listitem>
       <para>
        Controls which message levels are sent to the client.
        Valid values are <literal>DEBUG5</>,
        <literal>DEBUG4</>, <literal>DEBUG3</>, <literal>DEBUG2</>,
        <literal>DEBUG1</>, <literal>LOG</>, <literal>NOTICE</>,
        <literal>WARNING</>, and <literal>ERROR</>.  Each level
        includes all the levels that follow it.  The later the level,
        the fewer messages are sent.  The default is
        <literal>NOTICE</>.  Note that <literal>LOG</> has a different
        rank here than in <varname>log_min_messages</>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><varname>log_min_messages</varname> (<type>string</type>)</term>
      <listitem>
       <para>
        Controls which message levels are written to the server log.
        Valid values are <literal>DEBUG5</>, <literal>DEBUG4</>,
        <literal>DEBUG3</>, <literal>DEBUG2</>, <literal>DEBUG1</>,
        <literal>INFO</>, <literal>NOTICE</>, <literal>WARNING</>,
        <literal>ERROR</>, <literal>LOG</>, <literal>FATAL</>, and
        <literal>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 <literal>NOTICE</>.  Note that
        <literal>LOG</> has a different rank here than in
        <varname>client_min_messages</>.
        Only superusers can increase this option.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><varname>log_error_verbosity</varname> (<type>string</type>)</term>
      <listitem>
       <para>
        Controls the amount of detail written in the server log for each
        message that is logged.  Valid values are <literal>TERSE</>,
        <literal>DEFAULT</>, and <literal>VERBOSE</>, each adding more
        fields to displayed messages.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><varname>log_min_error_statement</varname> (<type>string</type>)</term>
      <listitem>
       <para>
        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 a
        higher level, are logged.  The default is
        <literal>PANIC</literal> (effectively turning this feature
        off for normal use). Valid values are <literal>DEBUG5</literal>,
        <literal>DEBUG4</literal>, <literal>DEBUG3</literal>,
        <literal>DEBUG2</literal>, <literal>DEBUG1</literal>,
        <literal>INFO</literal>, <literal>NOTICE</literal>,
        <literal>WARNING</literal>, <literal>ERROR</literal>,
        <literal>FATAL</literal>, and <literal>PANIC</literal>.  For
        example, if you set this to <literal>ERROR</literal> 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 increase this option.
       </para>
      </listitem>
     </varlistentry>
     
     <varlistentry>
      <term><varname>log_min_duration_statement</varname> (<type>integer</type>)</term>
       <listitem>
        <para>
         Sets a minimum statement execution time (in milliseconds)
         for statement to be logged.  All SQL statements
         that run in the time specified or longer will be logged with
         their duration.  Setting this to zero will print
         all queries and their durations.  Minus-one (the default)
         disables this.  For example, if you set it to 
         <literal>250</literal> 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.
         Only superusers can increase this or set it to minus-one if this 
         option is set by the administrator.
        </para>
       </listitem>
      </varlistentry>

     <varlistentry>
      <term><varname>silent_mode</varname> (<type>boolean</type>)</term>
      <listitem>
       <para>
        Runs the server silently. If this option is set, the server
        will automatically run in background and any controlling terminals
        are disassociated.  Thus, no messages are written to standard
        output or standard error (same effect as <command>postmaster</>'s <option>-S</option>
        option). Unless
        <application>syslog</> logging is enabled, using this option is
        discouraged since it makes it impossible to see error messages.
       </para>
      </listitem>
     </varlistentry>

     </variablelist>

       <para>
        Here is a list of the various message severity levels used in
        these settings:
        <variablelist>
         <varlistentry>
          <term><literal>DEBUG[1-5]</literal></term>
          <listitem>
           <para>
            Provides information for use by developers.
           </para>
          </listitem>
         </varlistentry>

         <varlistentry>
          <term><literal>INFO</literal></term>
          <listitem>
           <para>
            Provides information implicitly requested by the user,
            e.g., during <command>VACUUM VERBOSE</>.
           </para>
          </listitem>
         </varlistentry>

         <varlistentry>
          <term><literal>NOTICE</literal></term>
          <listitem>
           <para>
            Provides information that may be helpful to users, e.g.,
            truncation of long identifiers and the creation of indexes as part
            of primary keys.
           </para>
          </listitem>
         </varlistentry>

         <varlistentry>
          <term><literal>WARNING</literal></term