Re: On disable_cost
Laurenz Albe <laurenz.albe@cybertec.at>
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Alena Rybakina <a.rybakina@postgrespro.ru>, Robert Haas <robertmhaas@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-11T13:16:52Z
Lists: pgsql-hackers
On Fri, 2024-10-11 at 20:45 +1300, David Rowley wrote: > diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml > index ff689b6524..861b9cf0bc 100644 > --- a/doc/src/sgml/perform.sgml > +++ b/doc/src/sgml/perform.sgml > @@ -578,6 +578,34 @@ WHERE t1.unique1 < 100 AND t1.unique2 = t2.unique2; > discussed <link linkend="using-explain-analyze">below</link>. > </para> > > + <para> > + When using the enable/disable flags to disable plan node types, the > + majority of the flags only deprioritize the corresponding plan node I don't like "deprioritize". How about "discourage the use of"? Besides, is that really the majority? I had though that only a few nodes are unavoidable (sequential scan, sort, nested loop). But I guess I am wrong. > + and don't outright disallow the planner's ability to use the plan node > + type. This is done so that the planner still maintains the ability to > + form a plan for a given query. Otherwise, certain queries would not be > + possible to execute when certain plan node types are disabled. This means "would not be possible to execute" can be simplified to "could be executed". > + it is possible that the planner chooses a plan using a node that has been > + disabled. When this happens, the <command>EXPLAIN</command> output will > + indicate this fact. > + > +<screen> > +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 > +</screen> > + </para> > + > + <para> > + Because the <literal>unit</literal> table has no indexes, there is no > + other means to read the table data, so the <literal>Seq Scan</literal> > + is the only option available to the query planner. > + </para> > + Can we have "sequential scan" instead of "Seq Scan"? It's somewhat unrelated, but I cannot count how many people I have talked to who think that it is a "sequence scan". Yours, Laurenz Albe
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