Re: disfavoring unparameterized nested loops

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: disfavoring unparameterized nested loops
Дата
Msg-id CAApHDvq0DvZ9J45CU2_rUu0SpUvKk7MYaUKEXC22C6ZiPaHC6w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: disfavoring unparameterized nested loops  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: disfavoring unparameterized nested loops  (Peter Geoghegan <pg@bowt.ie>)
Список pgsql-hackers
On Wed, 16 Jun 2021 at 12:11, Peter Geoghegan <pg@bowt.ie> wrote:
> Whether or not we throw the plan back at the planner or "really change
> our minds at execution time" seems like a distinction without a
> difference.

What is "really change our minds at execution time"?  Is that switch
to another plan without consulting the planner?  If so what decides
what that new plan should be? The planner is meant to be the expert in
that department. The new information might cause the join order to
completely change. It might not be as simple as swapping a Nested Loop
for a Hash Join.

> Either way we're changing our minds about the plan based
> on information that is fundamentally execution time information, not
> plan time information. Have I missed something?

I don't really see why you think the number of rows that a given join
might produce is execution information. It's exactly the sort of
information the planner needs to make a good plan. It's just that
today we get that information from statistics. Plenty of other DBMSs
make decisions from sampling. FWIW, we do already have a minimalist
sampling already in get_actual_variable_range().

I'm just trying to highlight that I don't think overloading nodes is a
good path to go down.  It's not a sustainable practice. It's a path
towards just having a single node that does everything. If your
suggestion was not serious then there's no point in discussing it
further.

David



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Different compression methods for FPI
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Improving the isolationtester: fewer failures, less delay