Re: On disable_cost
Alena Rybakina <a.rybakina@postgrespro.ru>
From: Alena Rybakina <a.rybakina@postgrespro.ru>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Robert Haas <robertmhaas@gmail.com>, David Rowley <dgrowleyml@gmail.com>,
Tom Lane <tgl@sss.pgh.pa.us>, Heikki Linnakangas <hlinnaka@iki.fi>,
Peter Geoghegan <pg@bowt.ie>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-10-08T15:12:36Z
Lists: 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 < 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
Commits
-
Doc: add detail about EXPLAIN's "Disabled" property
- 84b8fccbe5c2 18.0 landed
-
Adjust EXPLAIN's output for disabled nodes
- 161320b4b960 18.0 landed
-
Fix order of parameters in a cost_sort call
- 87b6c3c0b703 18.0 landed
-
Show number of disabled nodes in EXPLAIN ANALYZE output.
- c01743aa4866 18.0 landed
-
Treat number of disabled nodes in a path as a separate cost metric.
- e22253467942 18.0 landed
-
Remove grotty use of disable_cost for TID scan plans.
- e4326fbc60c4 18.0 landed