On Mon, 2024-10-07 at 10:17 +0300, Alena Rybakina wrote: > > diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml > > index ff689b65245..db906841472 100644 > > --- a/doc/src/sgml/perform.sgml > > +++ b/doc/src/sgml/perform.sgml > > @@ -578,6 +578,28 @@ WHERE t1.unique1 < 100 AND t1.unique2 = t2.unique2; > > discussed <link linkend="using-explain-analyze">below</link>. > > </para> > > > > + <para> > > + Some plan node types cannot be completely disabled. For example, > > there is > > + no other access method than a sequential scan for a table with no > > index. > > + If you told the planner to disregard a certain node type, but it is > > forced > > + to use it nonetheless, you will see the plan node marked as > > + <quote>Disabled</quote> in the output of <command>EXPLAIN</command>: > > + > > +<screen> > > +CREATE TABLE dummy (t text); > > + > > +SET enable_seqscan = off; > > + > > +EXPLAIN SELECT * FROM dummy; > > + > > + QUERY PLAN > > +---------------------------------------------------------- > > + Seq Scan on dummy (cost=0.00..23.60 rows=1360 width=32) > > + Disabled: true > > +</screen> > > + > > + </para> > > + > > <para> > > <indexterm> > > <primary>subplan</primary> > > I think this is not entirely correct. I tested last version of the > patch [0]: I created a table and disabled sequential scanning, so > there were no other options for optimizer to scan table t1. it still > displayed that it has disabled nodes.
Isn't that exactly what my doc patch shows? > However you are right that this display will not appear for all > nodes that only contain a data collection procedure, such as Append, > MergeAppend, Gather, etc. And I agree with you that we should > information about it. I also think it’s worth adding additional > information that this option does not appear in the postgres_fdw > extension. I cannot quite follow that either... Yours, Laurenz Albe
