Re: Making Vars outer-join aware

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Richard Guo <guofenglinux(at)gmail(dot)com>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, "Finnerty, Jim" <jfinnert(at)amazon(dot)com>
Subject: Re: Making Vars outer-join aware
Date: 2023-02-13 16:50:17
Message-ID: 1223373.1676307017@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> Thanks for the report! I've looked at it a little bit and traced down
> to function have_unsafe_outer_join_ref(). The comment there says
> * In practice, this test never finds a problem ...
> This seems not correct as showed by the counterexample.

Right. I'd noticed that the inner loop of that function was not
reached in our regression tests, and incorrectly concluded that it
was not reachable --- but I failed to consider cases where the
inner rel's parameterization depends on Vars from multiple places.

> The NOT_USED part of code is doing this check. But I think we need a
> little tweak. We should check the nullable side of related outer joins
> against the satisfied part, rather than inner_paramrels. Maybe
> something like attached.

Agreed.

> However, this test seems to cost some cycles after the change. So I
> wonder if it's worthwhile to perform it, considering that join order
> restrictions should be able to guarantee there is no problem here.

Yeah, I think we should reduce it to an Assert check. It shouldn't be
worth the cycles to run in production, and that will also make it easier
to notice in sqlsmith testing if anyone happens across another
counterexample.

Pushed that way. Thanks for the report and the patch!

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2023-02-13 17:01:20 BRIN indexes vs. SK_SEARCHARRAY (and preprocessing scan keys)
Previous Message Andres Freund 2023-02-13 16:47:12 Re: Time delayed LR (WAS Re: logical replication restrictions)