Re: On disable_cost

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: On disable_cost
Дата
Msg-id CA+Tgmoaow5wsubUvbn3GUosL6-opRG1Do5p8Q1Dj--OudUTWJQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: On disable_cost  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: On disable_cost
Re: On disable_cost
Список pgsql-hackers
On Tue, May 7, 2024 at 4:19 PM Robert Haas <robertmhaas@gmail.com> wrote:
> Here are some patches for discussion.

Well, that didn't generate much discussion, but here I am trying
again. Here I've got patches 0001 and 0002 from my previous posting;
I've dropped 0003 and 0004 from the previous set for now so as not to
distract from the main event, but they may still be a good idea.
Instead I've got an 0003 and an 0004 that implement the "count of
disabled nodes" approach that we have discussed previously. This seems
to work fine, unlike the approaches I tried earlier. I think this is
the right direction to go, but I'd like to know what concerns people
might have.

This doesn't completely remove disable_cost, because hash joins still
add it to the cost when it's impossible to fit the MCV value into
work_mem. I'm not sure what to do with that. Continuing to use
disable_cost in that one scenario seems OK to me. We could
alternatively make that scenario bump disabled_nodes, but I don't
really want to confuse the planner not wanting to do something with
the user telling the planner not to do something, so I don't think
that's a good idea. Or we could rejigger things so that in that case
we don't generate the plan at all. I'm not sure why we don't do that
already, actually.

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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jelte Fennema-Nio
Дата:
Сообщение: Re: RFC: adding pytest as a supported test framework
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Remove dependence on integer wrapping