Hi!
On 02.10.2024 21:04, Laurenz Albe wrote:
I didn't want a running total, but maybe I misunderstood what a disabled
node is; see below.
If you see a join where two plans were disabled, that's useful information.
I'm not sure if I follow what you mean here. The patch will show
"Disabled: true" for both the inner and outer side of the join if both
of those are disabled. The difference is that my patch does not show
the join itself is disabled like master does. I thought that's what
you were complaining about. Can you show an example of what you mean?
I ran the following example, and now I am confused.
CREATE TABLE tab_a (id integer);
CREATE TABLE tab_b (id integer);
SET enable_nestloop = off; SET enable_hashjoin = off;
EXPLAIN SELECT * FROM tab_a JOIN tab_b USING (id);
QUERY PLAN ═════════════════════════════════════════════════════════════════════ Merge Join (cost=359.57..860.00 rows=32512 width=4) Merge Cond: (tab_a.id = tab_b.id) -> Sort (cost=179.78..186.16 rows=2550 width=4) Sort Key: tab_a.id -> Seq Scan on tab_a (cost=0.00..35.50 rows=2550 width=4) -> Sort (cost=179.78..186.16 rows=2550 width=4) Sort Key: tab_b.id -> Seq Scan on tab_b (cost=0.00..35.50 rows=2550 width=4)
I would have expected to see "Disabled nodes: 2" with the merge join,
because both the nested loop join and the hash join have been disabled.
Why is there no disabled node shown?
Disabled nodes show the number of disabled paths, you simply don’t have them here in mergejoin, because hashjoin and nestedloop were not selected. The reason is the compare_path_costs_fuzzily function, because the function decides which path is better based on fewer disabled nodes. hashjoin and nestedloop have 1 more nodes compared to mergejoin. you can disable mergejoin, I think the output about this will appear.
--
Regards,
Alena Rybakina
Postgres Professional
