From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Alena Rybakina <a(dot)rybakina(at)postgrespro(dot)ru> |
Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: On disable_cost |
Date: | 2024-10-02 19:05:18 |
Message-ID: | 77193cd406e6d448baf09e669377cbdcb08b1850.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 2024-10-02 at 21:13 +0300, Alena Rybakina wrote:
> > 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.
I see; the merge join happened to be the preferred join path, so nothing
had to be excluded.
/* reset all parameters */
EXPLAIN (COSTS OFF) SELECT * FROM tab_a JOIN tab_b USING (id);
QUERY PLAN
═════════════════════════════════════
Merge Join
Merge Cond: (tab_a.id = tab_b.id)
-> Sort
Sort Key: tab_a.id
-> Seq Scan on tab_a
-> Sort
Sort Key: tab_b.id
-> Seq Scan on tab_b
So now if I disable merge joins, I should get a different strategy and see
a disabled node, right?
SET enable_mergejoin = off;
EXPLAIN (COSTS OFF) SELECT * FROM tab_a JOIN tab_b USING (id);
QUERY PLAN
════════════════════════════════════
Hash Join
Hash Cond: (tab_a.id = tab_b.id)
-> Seq Scan on tab_a
-> Hash
-> Seq Scan on tab_b
No disabled node shown... Ok, I still don't get it.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2024-10-02 19:08:03 | Re: On disable_cost |
Previous Message | Tom Lane | 2024-10-02 19:00:30 | Re: pg_verifybackup: TAR format backup verification |