Re: Ignored join clause - Mailing list pgsql-bugs

From Andrew Gierth
Subject Re: Ignored join clause
Date
Msg-id 87efjbe8rz.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: Ignored join clause  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: Ignored join clause  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Ignored join clause  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
>>>>> "Andrew" == Andrew Gierth <andrew@tao11.riddles.org.uk> writes:

 Andrew> My suspicion is that this is an interaction between lateral and
 Andrew> join reordering. Looking into it further.

I think I was wrong, and that in fact this is a much more general
problem which amounts to a lack of communication between
get_joinrel_parampathinfo and extract_actual_join_clauses.

When we build the hash join path between q1 and q2,
get_joinrel_parampathinfo adds the q1.x=t.x clause to the
restrict_clauses list, but it doesn't distinguish it in any way from the
clauses that were there already.

Later when building the final Plan node for the hash join, we call
extract_actual_join_clauses to determine which clauses are join clauses
rather than filters. But this only looks at the RestrictInfo's
is_pushed_down field, and in this case that's wrong; is_pushed_down
isn't set, because the condition really was a join clause at the place
where it was originally written, but the condition has now been moved
from its original place by the parameterization and is effectively
pushed down even though it's not marked as such. So it ends up on the
wrong list.

-- 
Andrew (irc:RhodiumToad)


pgsql-bugs by date:

Previous
From: Greg Clough
Date:
Subject: RE: BUG #15162: individual user can connect from anywhere withpgadmin
Next
From: Tom Lane
Date:
Subject: Re: Ignored join clause