Re: disfavoring unparameterized nested loops - Mailing list pgsql-hackers

From Robert Haas
Subject Re: disfavoring unparameterized nested loops
Date
Msg-id CA+TgmoZ2mte6psjkQaRh6aiy=OSTK0fRpUCS2iahXPb_Vsiw5w@mail.gmail.com
Whole thread Raw
In response to Re: disfavoring unparameterized nested loops  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: disfavoring unparameterized nested loops  (Peter Geoghegan <pg@bowt.ie>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: [PATCH] Add sortsupport for range types and btree_gist
Next
From: Zhihong Yu
Date:
Subject: Re: Bloom filter Pushdown Optimization for Merge Join