Index: doc/src/sgml/runtime.sgml
===================================================================
RCS file: /var/lib/cvs/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.234
diff -c -r1.234 runtime.sgml
*** doc/src/sgml/runtime.sgml	25 Jan 2004 03:30:00 -0000	1.234
--- doc/src/sgml/runtime.sgml	27 Jan 2004 04:57:31 -0000
***************
*** 1462,1472 ****
        <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>
--- 1462,1472 ----
        <term><varname>from_collapse_limit</varname> (<type>integer</type>)</term>
        <listitem>
         <para>
!         The planner will merge sub-queries into upper queries if the
!         resulting <literal>FROM</literal> 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>
***************
*** 1475,1488 ****
        <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>
--- 1475,1520 ----
        <term><varname>join_collapse_limit</varname> (<type>integer</type>)</term>
        <listitem>
         <para>
!         The planner will rewrite explicit inner <literal>JOIN</>
!         constructs into lists of <literal>FROM</> items whenever a
!         list of no more than this many items in total would
!         result. Prior to <productname>PostgreSQL</> 7.4, joins
!         specified via the <literal>JOIN</literal> 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 variable controls
!         the extent to which this reordering is performed.
!         <note>
!          <para>
!           The order of outer joins specified via the <literal>JOIN</>
!           construct is never adjusted by the query planner; therefore,
!           <varname>join_collapse_limit</> has no effect on this
!           behavior.
!          </para>
!         </note>
!        </para>
! 
!        <para>
!         By default, this variable is set to
!         <varname>from_collapse_limit</varname>, which is appropriate
!         for most users. Setting it to 1 prevents any reordering of
!         inner <literal>JOIN</>s. 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 explicitely. Another consequence of setting
!         this variable to 1 is that the query planner will behave more
!         similarly to the <productname>PostgreSQL</productname> 7.3
!         query planner, which some users might find useful for backward
!         compatibility reasons.
!        </para>
! 
!        <para>
!         Setting this variable to a value between 1 and
!         <varname>from_collapse_limit</varname> might be useful to
!         trade off planning time against the quality of the chosen plan
!         (higher values produce better plans).
         </para>
        </listitem>
       </varlistentry>
***************
*** 2583,2591 ****
        <term><varname>max_identifier_length</varname> (<type>integer</type>)</term>
        <listitem>
         <para>
!         Shows the maximum identifier length. It is determined as one less than
!         the value of <literal>NAMEDATALEN</> when building the server. The
!         default value of NAMEDATALEN is 64; therefore the default
          <varname>max_identifier_length</varname> is 63.
         </para>
        </listitem>
--- 2615,2624 ----
        <term><varname>max_identifier_length</varname> (<type>integer</type>)</term>
        <listitem>
         <para>
!         Shows the maximum identifier length. It is determined as one
!         less than the value of <literal>NAMEDATALEN</> when building
!         the server. The default value of <literal>NAMEDATALEN</> is
!         64; therefore the default
          <varname>max_identifier_length</varname> is 63.
         </para>
        </listitem>