aboutsummaryrefslogtreecommitdiff
path: root/doc/src
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2012-04-09 20:49:06 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2012-04-09 20:49:06 -0400
commit5cf6fddd63c29daab6daa6d0981d51c5f64b876a (patch)
tree1ce59ba9829692a0238351cb22ddfbc415d74d93 /doc/src
parent0e20abdb47e3499353ac4fd1b2d21e82ec6b1461 (diff)
downloadpostgresql-5cf6fddd63c29daab6daa6d0981d51c5f64b876a.tar.gz
postgresql-5cf6fddd63c29daab6daa6d0981d51c5f64b876a.zip
Adjust various references to GEQO being non-deterministic.
It's still non-deterministic in some sense ... but given fixed settings and identical planning problems, it will now always choose the same plan, so we probably shouldn't tar it with that brush. Per bug #6565 from Guillaume Cottenceau. Back-patch to 9.0 where the behavior was fixed.
Diffstat (limited to 'doc/src')
-rw-r--r--doc/src/sgml/config.sgml15
1 files changed, 8 insertions, 7 deletions
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 8187d367f74..1d359dacb3d 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -2622,8 +2622,7 @@ SET ENABLE_SEQSCAN TO OFF;
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>
@@ -2662,9 +2661,11 @@ SET ENABLE_SEQSCAN TO OFF;
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>
@@ -2876,7 +2877,7 @@ SELECT * FROM parent WHERE key = 2400;
<para>
Setting this value to <xref linkend="guc-geqo-threshold"> or more
- may trigger use of the GEQO planner, resulting in nondeterministic
+ may trigger use of the GEQO planner, resulting in non-optimal
plans. See <xref linkend="runtime-config-query-geqo">.
</para>
</listitem>
@@ -2911,7 +2912,7 @@ SELECT * FROM parent WHERE key = 2400;
<para>
Setting this value to <xref linkend="guc-geqo-threshold"> or more
- may trigger use of the GEQO planner, resulting in nondeterministic
+ may trigger use of the GEQO planner, resulting in non-optimal
plans. See <xref linkend="runtime-config-query-geqo">.
</para>
</listitem>