On Thu, 2024-10-03 at 14:24 -0400, Robert Haas wrote: > On Thu, Oct 3, 2024 at 1:35 PM Alena Rybakina <a.rybak...@postgrespro.ru> > wrote: > > I prepared a patch that includes the information we can add. > > One general thing to think about is that we really document very > little about EXPLAIN. That might not be good, but we should consider > whether it will look strange if we document a bunch of stuff about > this and still don't talk about anything else. > > (This is not a comment on this specific patch, which I have not > examined. It's just a general thought.)
The "EXPLAIN Basics" already mention "enable_seqscan", so I think it is alright to expand on that a bit. Here is my take on a documentation patch (assuming David's "Disabled: true" wording): 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> Yours, Laurenz Albe