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
