Re: On disable_cost
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Laurenz Albe <laurenz.albe@cybertec.at>
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-18T10:54:49Z
Lists: pgsql-hackers
Attachments
- disabled_docs_v2.patch (application/octet-stream) patch v2
On Sat, 12 Oct 2024 at 02:16, Laurenz Albe <laurenz.albe@cybertec.at> wrote: > > On Fri, 2024-10-11 at 20:45 +1300, David Rowley wrote: > > + 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"? Yeah, that's ok for me. > 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. Ok, I looked and you're right. I did make a quick pass to approximately figure that out and I came up with: Soft disable: enable_bitmapscan, enable_gathermerge, enable_hashagg, enable_hashjoin, enable_indexscan, enable_mergejoin, enable_nestloop, enable_seqscan, enable_sort That's 9. Hard disable: enable_async_append, enable_group_by_reordering, enable_incremental_sort, enable_indexonlyscan, enable_material, enable_memoize, enable_parallel_append, enable_parallel_hash, enable_partition_pruning, enable_partitionwise_aggregate, enable_partitionwise_join, enable_presorted_aggregate, enable_tidscan And 13. (there are a few ones that are in a grey area such as enable_hashagg or enable_tidscan will still happen with a WHERE CURRENT OF <cursor>.) I changed "majority" to "many" > > + 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". Changed. > 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". Yeah, looks like we only call it "Seq Scan" in EXPLAIN and we use "sequence scan" when talking about it in sentences. Thanks for looking. Updated patch is attached. David
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