Re: On disable_cost

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

In response to

Responses

Browse pgsql-hackers by date

  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