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

From Peter Geoghegan
Subject Re: disfavoring unparameterized nested loops
Date
Msg-id CAH2-WzmAoowqFAG7s2paVMkXLWP0YFXVp29a2tPoqw6u0W=J5Q@mail.gmail.com
Whole thread Raw
In response to Re: disfavoring unparameterized nested loops  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
On Thu, Sep 29, 2022 at 9:00 PM David Rowley <dgrowleyml@gmail.com> wrote:
> I understand that what you propose would be a fast way to fix this
> issue. However, if we went and changed the join path creation code to
> not add non-parameterised nested loop paths when other paths exist,
> then how could we ever dare to put that code back again when we come
> up with a better solution?

But why would it matter, even then?

I don't deny that something like that could make sense, but I don't
see why it should be in tension with this proposal. We're talking
about a plan shape that is (in practical terms) inherently
unreasonable, given the availability of an alternative plan shape. Why
wouldn't that continue to be true in every such case, forever?

To put it another way, the proposal seems like taking away something
that we don't want to have, ever. It seems like a subtractive thing to
me. The potential upside of allowing unparameterized nestloop joins
seems infinitesimal; zero for all practical purposes. So even with a
far more sophisticated framework for "plan riskiness" in place, it
would still make sense to treat unparameterized nestloop joins as
inherently undesirable. There is perhaps a theoretical sense in which
that isn't quite true, but it's true for all practical purposes, which
should be enough.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: disfavoring unparameterized nested loops
Next
From: Justin Pryzby
Date:
Subject: Re: EINTR in ftruncate()