Re: Making Vars outer-join aware - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Making Vars outer-join aware
Date
Msg-id 1903934.1657031040@sss.pgh.pa.us
Whole thread Raw
In response to Re: Making Vars outer-join aware  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: Making Vars outer-join aware
List pgsql-hackers
Richard Guo <guofenglinux@gmail.com> writes:
> For the query in the example

>     SELECT * FROM t1 LEFT JOIN t2 ON (t1.x = t2.y) WHERE foo(t2.z)

> (foo() is not strict.) We want to avoid pushing foo(t2.z) down to the t2
> scan level. Previously we do that with check_outerjoin_delay() by
> scanning all the outer joins below and check if the qual references any
> nullable rels of the OJ, and if so include the OJ's rels into the qual.
> So as a result we'd get that foo(t2.z) is referencing t1 and t2, and
> we'd put the qual into the join lists of t1 and t2.

> Now there is the 'varnullingrels' marker in the t2.z, which is the LEFT
> JOIN below (with RTI 3). So we consider the qual is referencing RTE 2
> (which is t2) and RTE 3 (which is the OJ). Do we still need to include
> RTE 1, i.e. t1 into the qual's required relids? How should we do that?

It seems likely to me that we could leave the qual's required_relids
as just {2,3} and not have to bother ORing any additional bits into
that.  However, in the case of a Var-free JOIN/ON clause it'd still
be necessary to artificially add some relids to its initially empty
relids.  Since I've not yet tried to rewrite distribute_qual_to_rels
I'm not sure how the details will shake out.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Fix proposal for comparaison bugs in PostgreSQL::Version
Next
From: Laurenz Albe
Date:
Subject: Re: Wrong provolatile value for to_timestamp (1 argument)