On Thu, 2024-10-03 at 14:24 -0400, Robert Haas wrote:
> On Thu, Oct 3, 2024 at 1:35 PM Alena Rybakina <a.rybakina@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
