Re: On disable_cost - Mailing list pgsql-hackers

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.)

I think we should still add it because it might cause a lot of misunderstanding.

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>

Sorry for the late reply, I needed time to look into this feature to respond to your email.
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.
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.

-- 
Regards,
Alena Rybakina
Postgres Professional