Re: Why enable_hashjoin Completely disables HashJoin - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Why enable_hashjoin Completely disables HashJoin
Date
Msg-id CA+TgmoY2+KB_4_oaQ2NN-CcUmNrWvzNNzgVNo3dLO59rc2WD=g@mail.gmail.com
Whole thread Raw
In response to Re: Why enable_hashjoin Completely disables HashJoin  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Why enable_hashjoin Completely disables HashJoin  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Apr 3, 2023 at 8:13 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Personally, I'd get rid of disable_cost altogether if I could.
> I'm not in a hurry to extend its use to more places.

I agree. I've wondered if we should put some work into that. It feels
bad to waste CPU cycles generating paths we intend to basically just
throw away, and it feels even worse if they manage to beat out some
other path on cost.

It hasn't been obvious to me how we could restructure the existing
logic to avoid relying on disable_cost. I sort of feel like it should
be a two-pass algorithm: go through and generate all the path types
that aren't disabled, and then if that results in no paths, try a
do-over where you ignore the disable flags (or just some of them). But
the code structure doesn't seem particularly amenable to that kind of
thing.

This hasn't caused me enough headaches yet that I've been willing to
invest time in it, but it has caused me more than zero headaches...

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: possible proposal plpgsql GET DIAGNOSTICS oid = PG_ROUTINE_OID
Next
From: Fujii Masao
Date:
Subject: Re: [Proposal] Add foreign-server health checks infrastructure