Re: Why enable_hashjoin Completely disables HashJoin

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Why enable_hashjoin Completely disables HashJoin
Дата
Msg-id CA+TgmoY2+KB_4_oaQ2NN-CcUmNrWvzNNzgVNo3dLO59rc2WD=g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Why enable_hashjoin Completely disables HashJoin  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Why enable_hashjoin Completely disables HashJoin  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: possible proposal plpgsql GET DIAGNOSTICS oid = PG_ROUTINE_OID
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: [Proposal] Add foreign-server health checks infrastructure