database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-05-01 01:04:50 +03:00
Code

Adjust various references to GEQO being non-deterministic.

Browse Source 
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.
This commit is contained in:
Tom Lane 2012-04-09 20:49:01 -04:00
parent 17665f6115
commit c94b43ce39
1 changed files with 9 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
doc/src/sgml/config.sgml
View File

@ -2784,8 +2784,7 @@ SET ENABLE_SEQSCAN TO OFF;
planning using heuristic searching. This reduces planning time for planning using heuristic searching. This reduces planning time for
complex queries (those joining many relations), at the cost of producing complex queries (those joining many relations), at the cost of producing
plans that are sometimes inferior to those found by the normal plans that are sometimes inferior to those found by the normal
exhaustive-search algorithm. Also, GEQO's searching is randomized and exhaustive-search algorithm.
therefore its plans may vary nondeterministically.
For more information see <xref linkend="geqo">. For more information see <xref linkend="geqo">.
</para> </para>
@ -2824,9 +2823,11 @@ SET ENABLE_SEQSCAN TO OFF;
this many <literal>FROM</> items involved. (Note that a this many <literal>FROM</> items involved. (Note that a
<literal>FULL OUTER JOIN</> construct counts as only one <literal>FROM</> <literal>FULL OUTER JOIN</> construct counts as only one <literal>FROM</>
item.) The default is 12. For simpler queries it is usually best item.) The default is 12. For simpler queries it is usually best
to use the deterministic, exhaustive planner, but for queries with to use the regular, exhaustive-search planner, but for queries with
many tables the deterministic planner takes too long, often many tables the exhaustive search takes too long, often
longer than the penalty of executing a suboptimal plan. 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> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -3038,7 +3039,7 @@ SELECT * FROM parent WHERE key = 2400;
<para> <para>
Setting this value to <xref linkend="guc-geqo-threshold"> or more 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">. plans. See <xref linkend="runtime-config-query-geqo">.
</para> </para>
</listitem> </listitem>
@ -3073,7 +3074,7 @@ SELECT * FROM parent WHERE key = 2400;
<para> <para>
Setting this value to <xref linkend="guc-geqo-threshold"> or more 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">. plans. See <xref linkend="runtime-config-query-geqo">.
</para> </para>
</listitem> </listitem>
@ -4299,7 +4300,7 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
displayed in <xref linkend="pg-stat-database-view">, in the output of displayed in <xref linkend="pg-stat-database-view">, in the output of
<xref linkend="sql-explain"> when the <literal>BUFFERS</> option is <xref linkend="sql-explain"> when the <literal>BUFFERS</> option is
used, and by <xref linkend="pgstatstatements">. Only superusers can used, and by <xref linkend="pgstatstatements">. Only superusers can
change this setting. change this setting.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>