Re: On disable_cost - Mailing list pgsql-hackers

From Alena Rybakina
Subject Re: On disable_cost
Date
Msg-id bc01b846-a686-4d48-9d59-c245c7e4871b@postgrespro.ru
Whole thread Raw
In response to Re: On disable_cost  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: On disable_cost
List pgsql-hackers


On 07.10.2024 19:02, Laurenz Albe wrote:
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 &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>
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?
Sorry, you are right and this is correct. I think I misunderstood at first because I was tired
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...


I meant this [0].

Th disabled description won't display if the MergeAppend and Append nodes are used in the query plan. I tried to generalize it, but without success. I'm not sure that these nodes can be called accumulating data. But I tried to describe this case in the documentation.

About postgres_fdw extension disabled nodes won't show [1]. I think we should add information about it too.

[0] https://www.postgresql.org/message-id/CAApHDvpMyKJpLGWRmR3%2B3g4DxrSf6iRpwTRCXMorU0HvgWbocw%40mail.gmail.com

[1] https://www.postgresql.org/message-id/CA%2BTgmoZRwy8202vxbUPBeZd_Tx5NYVtmpvBnJnOzZS3b81cpkg%40mail.gmail.com

-- 
Regards,
Alena Rybakina
Postgres Professional

pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Statistics Import and Export
Next
From: Jacob Champion
Date:
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER