planning using heuristic searching. This reduces planning time for

complex queries (those joining many relations), at the cost of producing

plans that are sometimes inferior to those found by the normal

exhaustive-search algorithm. Also, GEQO's searching is randomized and

therefore its plans may vary nondeterministically.

exhaustive-search algorithm.

For more information see <xref linkend="geqo">.

</para>

this many <literal>FROM</> items involved. (Note that a

<literal>FULL OUTER JOIN</> construct counts as only one <literal>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, often

longer than the penalty of executing a suboptimal plan.

to use the regular, exhaustive-search planner, but for queries with

many tables the exhaustive search takes too long, often

longer than the penalty of executing a suboptimal plan. Thus,

a threshold on the size of the query is a convenient way to manage

use of GEQO.

</para>

</listitem>

</varlistentry>

<para>

Setting this value to <xref linkend="guc-geqo-threshold"> or more

may trigger use of the GEQO planner, resulting innondeterministic

may trigger use of the GEQO planner, resulting innon-optimal

plans. See <xref linkend="runtime-config-query-geqo">.

</para>

</listitem>

<para>

Setting this value to <xref linkend="guc-geqo-threshold"> or more

may trigger use of the GEQO planner, resulting innondeterministic

may trigger use of the GEQO planner, resulting innon-optimal

plans. See <xref linkend="runtime-config-query-geqo">.

</para>

</listitem>