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 &lt; 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


Reply via email to