Re: disfavoring unparameterized nested loops

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: disfavoring unparameterized nested loops
Дата
Msg-id CA+TgmoZ2mte6psjkQaRh6aiy=OSTK0fRpUCS2iahXPb_Vsiw5w@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 Fri, Sep 30, 2022 at 2:24 PM Peter Geoghegan <pg@bowt.ie> wrote:
> It's not just that the risks are ludicrously high, of course. The
> potential benefits must *also* be very low. It's both factors,
> together.

Hmm, maybe. But it also wouldn't surprise me very much if someone can
come up with a test case where a nested loop with a single row (or
maybe no rows) on one side or the other and it's significantly faster
than any alternative plan. I believe, though, that even if such cases
exist, they are probably relatively few in number compared to the
cases where parameterized nested loops hurt, and the savings are
probably small compared to the multiple-orders-of-magnitude slowdowns
that you can get when a nested loop goes bad. But they might still be
relatively large -- 2x, 3x? -- in absolute terms.

In the prior discussion, the only person who showed a case in which he
thought that an unparameterized nested loop might be a clear winner
was Tom, but it was just sort of a general "this kind of case might be
a problem" thing rather than a fully worked out example with real
timings. Perhaps someone ought to try to characterize the kinds of
cases he mentioned, to help us get a clearer feeling about what, if
anything, we're gaining from the current scheme.

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



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [PATCH] Add sortsupport for range types and btree_gist
Следующее
От: Zhihong Yu
Дата:
Сообщение: Re: Bloom filter Pushdown Optimization for Merge Join