From 84b8fccbe5c21cc2a05f8cf91903cadc6ebfe680 Mon Sep 17 00:00:00 2001 From: David Rowley Date: Tue, 29 Oct 2024 23:28:12 +1300 Subject: [PATCH] Doc: add detail about EXPLAIN's "Disabled" property c01743aa4 and later 161320b4b adjusted the EXPLAIN output to show which plan nodes were chosen despite being disabled by the various enable* GUCs. Prior to e22253467, the disabledness of a node was only evident by a large startup cost penalty. Since we now explicitly tag disabled nodes with a boolean property in EXPLAIN, let's add some documentation to provide some details about why and when disabled nodes can appear in the plan. Author: Laurenz Albe, David Rowley Discussion: https://postgr.es/m/883729e429267214753d5e438c82c73a58c3db5d.camel@cybertec.at --- doc/src/sgml/perform.sgml | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml index ff689b65245..cd12b9ce48b 100644 --- a/doc/src/sgml/perform.sgml +++ b/doc/src/sgml/perform.sgml @@ -578,6 +578,31 @@ WHERE t1.unique1 < 100 AND t1.unique2 = t2.unique2; discussed below. + + When using the enable/disable flags to disable plan node types, many of + the flags only discourage the use of the corresponding plan node and don't + outright disallow the planner's ability to use the plan node type. This + is by design so that the planner still maintains the ability to form a + plan for a given query. When the resulting plan contains a disabled node, + the EXPLAIN output will indicate this fact. + + +SET enable_seqscan = off; +EXPLAIN SELECT * FROM unit; + + QUERY PLAN +--------------------------------------------------------- + Seq Scan on unit (cost=0.00..21.30 rows=1130 width=44) + Disabled: true + + + + + Because the unit table has no indexes, there is no + other means to read the table data, so the sequential scan is the only + option available to the query planner. + + subplan -- 2.30.2