On Fri, 2024-10-11 at 20:45 +1300, David Rowley wrote:
> diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml
> index ff689b6524..861b9cf0bc 100644
> --- a/doc/src/sgml/perform.sgml
> +++ b/doc/src/sgml/perform.sgml
> @@ -578,6 +578,34 @@ WHERE t1.unique1 < 100 AND t1.unique2 = t2.unique2;
> discussed <link linkend="using-explain-analyze">below</link>.
> </para>
>
> + <para>
> + When using the enable/disable flags to disable plan node types, the
> + majority of the flags only deprioritize the corresponding plan node
I don't like "deprioritize".
How about "discourage the use of"?
Besides, is that really the majority? I had though that only a few nodes
are unavoidable (sequential scan, sort, nested loop). But I guess I am wrong.
> + and don't outright disallow the planner's ability to use the plan node
> + type. This is done so that the planner still maintains the ability to
> + form a plan for a given query. Otherwise, certain queries would not be
> + possible to execute when certain plan node types are disabled. This means
"would not be possible to execute" can be simplified to "could be executed".
> + it is possible that the planner chooses a plan using a node that has been
> + disabled. When this happens, the <command>EXPLAIN</command> output will
> + indicate this fact.
> +
> +<screen>
> +SET enable_seqscan = off;
> +EXPLAIN SELECT * FROM unit;
> +
> + QUERY PLAN
> +---------------------------------------------------------
> + Seq Scan on unit (cost=0.00..21.30 rows=1130 width=44)
> + Disabled: true
> +</screen>
> + </para>
> +
> + <para>
> + Because the <literal>unit</literal> table has no indexes, there is no
> + other means to read the table data, so the <literal>Seq Scan</literal>
> + is the only option available to the query planner.
> + </para>
> +
Can we have "sequential scan" instead of "Seq Scan"?
It's somewhat unrelated, but I cannot count how many people I have talked
to who think that it is a "sequence scan".
Yours,
Laurenz Albe
