Horton

Re: Making Vars outer-join aware

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
Cc: Pg Hackers <pgsql-hackers@lists.postgresql.org>, "Finnerty, Jim" <jfinnert@amazon.com>
Date: 2022-12-27T15:31:20Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Re-allow INDEX_VAR as rt_index in ChangeVarNodes().

  2. Fix thinkos in have_unsafe_outer_join_ref; reduce to Assert check.

  3. Invent "join domains" to replace the below_outer_join hack.

  4. Do assorted mop-up in the planner.

  5. Make Vars be outer-join-aware.

  6. Invent "multibitmapsets", and use them to speed up antijoin detection.

  7. Add basic regression tests for semi/antijoin recognition.

  8. Improve performance of adjust_appendrel_attrs_multilevel.

  9. Refactor addition of PlaceHolderVars to joinrel targetlists.

  10. Use an explicit state flag to control PlaceHolderInfo creation.

  11. Make PlaceHolderInfo lookup O(1).

Richard Guo <guofenglinux@gmail.com> writes:
> For 0012, I'm still trying to understand JoinDomain.  AFAIU all EC
> members of the same EC should have the same JoinDomain, because for
> constants we match EC members only within the same JoinDomain, and for
> Vars if they come from different join domains they will have different
> nullingrels and thus will not match.  So I wonder if we can have the
> JoinDomain kept in EquivalenceClass rather than in each
> EquivalenceMembers.

Yeah, I tried to do it like that at first, and failed.  There is
some sort of association between ECs and join domains, for sure,
but exactly what it is seems to need more elucidation.

The thing that I couldn't get around before is that if you have,
say, a mergejoinable equality clause in an outer join:

    select ... from a left join b on a.x = b.y;

that equality clause can only be associated with the join domain
for B, because it certainly can't be enforced against A.  However,
you'd still wish to be able to do a mergejoin using indexes on
a.x and b.y, and this means that we have to understand the ordering
induced by a PathKey based on this EC as applicable to A, even
though that relation is not in the same join domain.  So there are
situations where sort orderings apply across domain boundaries even
though equalities don't.  We might have to split the notion of
EquivalenceClass into two sorts of objects, and somewhere right
about here is where I realized that this wasn't getting finished
for v16 :-(.

So the next pass at this is likely going to involve some more
refactoring, and maybe we'll end up saying that an EquivalenceClass
is tightly bound to a join domain or maybe we won't.  For the moment
it seemed to work better to associate domains with only the const
members of ECs.  (As written, the patch does fill em_jdomain even
for non-const members, but that was just for simplicity.  I'd
originally meant to make it NULL for non-const members, but that
turned out to be a bit too tedious because the responsibility for
marking a member as const or not is split among several places.)

Another part of the motivation for doing it like that is that
I've been thinking about having just a single common pool of
EquivalenceMember objects, and turning EquivalenceClasses into
bitmapsets of indexes into the shared EquivalenceMember list.
This would support having ECs that share some member(s) without
being exactly the same thing, which I think might be necessary
to get to the point of treating outer-join clauses as creating
EC equalities.

BTW, I can't escape the suspicion that I've reinvented an idea
that's already well known in the literature.  Has anyone seen
something like this "join domain" concept before, and if so
what was it called?

			regards, tom lane