11<!--
2- $PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.234 2004/01/25 03:30:00 momjian Exp $
2+ $PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.235 2004/01/27 16:51:43 neilc Exp $
33-->
44
55<Chapter Id="runtime">
@@ -1462,11 +1462,11 @@ SET ENABLE_SEQSCAN TO OFF;
14621462 <term><varname>from_collapse_limit</varname> (<type>integer</type>)</term>
14631463 <listitem>
14641464 <para>
1465- The planner will merge sub-queries into upper queries if the resulting
1466- FROM list would have no more than this many items. Smaller values
1467- reduce planning time but may yield inferior query plans.
1468- The default is 8. It is usually wise to keep this less than
1469- <varname>geqo_threshold</varname>.
1465+ The planner will merge sub-queries into upper queries if the
1466+ resulting <literal> FROM</literal> list would have no more than
1467+ this many items. Smaller values reduce planning time but may
1468+ yield inferior query plans. The default is 8. It is usually
1469+ wise to keep this less than <varname>geqo_threshold</varname>.
14701470 </para>
14711471 </listitem>
14721472 </varlistentry>
@@ -1475,14 +1475,48 @@ SET ENABLE_SEQSCAN TO OFF;
14751475 <term><varname>join_collapse_limit</varname> (<type>integer</type>)</term>
14761476 <listitem>
14771477 <para>
1478- The planner will flatten explicit inner <literal>JOIN</> constructs
1479- into lists of <literal>FROM</> items whenever a list of no more than
1480- this many items would result. Usually this is set the same as
1481- <varname>from_collapse_limit</>. Setting it to 1 prevents any
1482- flattening of inner <literal>JOIN</>s, allowing explicit
1483- <literal>JOIN</> syntax to be used to control the join order.
1484- Intermediate values might be useful to trade off planning time
1485- against quality of plan.
1478+ The planner will rewrite explicit inner <literal>JOIN</>
1479+ constructs into lists of <literal>FROM</> items whenever a
1480+ list of no more than this many items in total would
1481+ result. Prior to <productname>PostgreSQL</> 7.4, joins
1482+ specified via the <literal>JOIN</literal> construct would
1483+ never be reordered by the query planner. The query planner has
1484+ subsequently been improved so that inner joins written in this
1485+ form can be reordered; this configuration variable controls
1486+ the extent to which this reordering is performed.
1487+ <note>
1488+ <para>
1489+ At present, the order of outer joins specified via the
1490+ <literal>JOIN</> construct is never adjusted by the query
1491+ planner; therefore, <varname>join_collapse_limit</> has no
1492+ effect on this behavior. The planner may be improved to
1493+ reorder some classes of outer joins in a future release of
1494+ <productname>PostgreSQL</productname>.
1495+ </para>
1496+ </note>
1497+ </para>
1498+
1499+ <para>
1500+ By default, this variable is set to
1501+ <varname>from_collapse_limit</varname>, which is appropriate
1502+ for most uses. Setting it to 1 prevents any reordering of
1503+ inner <literal>JOIN</>s. Thus, the explicit join order
1504+ specified in the query will be the actual order in which the
1505+ relations are joined. The query planner does not always choose
1506+ the optimal join order; advanced users may elect to
1507+ temporarily set this variable to 1, and then specify the join
1508+ order they desire explicitly. Another consequence of setting
1509+ this variable to 1 is that the query planner will behave more
1510+ like the <productname>PostgreSQL</productname> 7.3 query
1511+ planner, which some users might find useful for backward
1512+ compatibility reasons.
1513+ </para>
1514+
1515+ <para>
1516+ Setting this variable to a value between 1 and
1517+ <varname>from_collapse_limit</varname> might be useful to
1518+ trade off planning time against the quality of the chosen plan
1519+ (higher values produce better plans).
14861520 </para>
14871521 </listitem>
14881522 </varlistentry>
@@ -2583,9 +2617,10 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
25832617 <term><varname>max_identifier_length</varname> (<type>integer</type>)</term>
25842618 <listitem>
25852619 <para>
2586- Shows the maximum identifier length. It is determined as one less than
2587- the value of <literal>NAMEDATALEN</> when building the server. The
2588- default value of NAMEDATALEN is 64; therefore the default
2620+ Shows the maximum identifier length. It is determined as one
2621+ less than the value of <literal>NAMEDATALEN</> when building
2622+ the server. The default value of <literal>NAMEDATALEN</> is
2623+ 64; therefore the default
25892624 <varname>max_identifier_length</varname> is 63.
25902625 </para>
25912626 </listitem>
