@@ -6304,63 +6304,6 @@ SELECT * FROM parent WHERE key = 2400;
63046304 </listitem>
63056305 </varlistentry>
63066306
6307- <varlistentry id="guc-or-to-any-transform-limit" xreflabel="or_to_any_transform_limit">
6308- <term><varname>or_to_any_transform_limit</varname> (<type>boolean</type>)
6309- <indexterm>
6310- <primary><varname>or_to_any_transform_limit</varname> configuration parameter</primary>
6311- </indexterm>
6312- </term>
6313- <listitem>
6314- <para>
6315- Sets the minimum length of arguments in an <literal>OR</literal>
6316- expression exceeding which planner will try to lookup and group
6317- multiple similar <literal>OR</literal> expressions to
6318- <literal>ANY</literal> (<xref linkend="functions-comparisons-any-some"/>)
6319- expressions. The grouping technique of this transformation is based
6320- on the equivalence of variable sides. One side of such an expression
6321- must be a constant clause, and the other must contain a variable
6322- clause. The default value is <literal>5</literal>. The value of
6323- <literal>-1</literal> completely disables the transformation.
6324- </para>
6325- <para>
6326- The advantage of this <literal>OR-to-ANY</literal> transformation is
6327- faster query planning and execution. In certain cases, this
6328- transformation also leads to more effective plans containing
6329- a single index scan instead of multiple bitmap scans. However, it
6330- may also cause a planning regression when distinct
6331- <literal>OR</literal> arguments are better to match to distinct indexes.
6332- This may happen when they have different matching partial indexes or
6333- have different distributions of other columns used in the query.
6334- Generally, more groupable <literal>OR</literal> arguments mean that
6335- transformation will be more likely to win than to lose.
6336- </para>
6337- <para>
6338- For example, this query has its set of five <literal>OR</literal>
6339- expressions transformed to <literal>ANY</literal> with the default
6340- value of <varname>or_to_any_transform_limit</varname>. But not with
6341- the increased value.
6342- <programlisting>
6343- # EXPLAIN SELECT * FROM tbl WHERE key = 1 OR key = 2 OR key = 3 OR key = 4 OR key = 5;
6344- QUERY PLAN
6345- -----------------------------------------------------
6346- Seq Scan on tbl (cost=0.00..51.44 rows=64 width=4)
6347- Filter: (key = ANY ('{1,2,3,4,5}'::integer[]))
6348- (2 rows)
6349-
6350- # SET or_to_any_transform_limit = 6;
6351- SET
6352-
6353- # EXPLAIN SELECT * FROM tbl WHERE key = 1 OR key = 2 OR key = 3 OR key = 4 OR key = 5;
6354- QUERY PLAN
6355- ---------------------------------------------------------------------------
6356- Seq Scan on tbl (cost=0.00..67.38 rows=63 width=4)
6357- Filter: ((key = 1) OR (key = 2) OR (key = 3) OR (key = 4) OR (key = 5))
6358- (2 rows)
6359- </programlisting>
6360- </para>
6361- </listitem>
6362- </varlistentry>
6363-
63646307 <varlistentry id="guc-plan-cache-mode" xreflabel="plan_cache_mode">
63656308 <term><varname>plan_cache_mode</varname> (<type>enum</type>)
63666309 <indexterm>