Robert Haas <robertmhaas@gmail.com> writes:
> So, it looks to me like the way this works today is that
> join_is_legal() figures out the relevant SpecialJoinInfo and then
> add_outer_joins_to_relids() decides what to add to the joinrel's relid
> set. So I think, though I am not quite sure, that if somewhere around
> that point in the code we copied sjinfo->ojrelid into the RelOptInfo,
> and then propagated that through to the final plan, that might be what
> you're looking for here.
Not the RelOptInfo, but the Path. I have not looked at details, but
it might be necessary to identify these labels at Path construction
time rather than reconstructing them during createplan.c. I'd rather
not, because bloating Path nodes with hopefully-redundant information
isn't attractive. But if it turns out that createplan.c doesn't have
enough information then we might have to.
I'm also thinking that this notion of starting/completing OJs might be
useful in its own right to clarify and even simplify some of the Path
manipulations we do. But that will require reviewing the code.
> So my counter-proposal is that this patch set should either (1) expose
> nothing at all about join RTIs because I don't have a need for them or
> (2) expose the join RTIs completed at a certain level because that's
> easily calculated from the data we already have; and if you want to
> later also expose the single join RTI started at a certain level for a
> varnullingrels cross-check or any other purpose, then you can propose
> a patch for that.
If what you want to do is only interested in baserel RTIs, then I
think we should leave outer join RTIs out of the discussion for the
present. I was not looking to make you do work you aren't interested
in. I reserve the right to do said work later ...
regards, tom lane
