Richard Guo <guofenglinux@gmail.com> writes:
> On Sun, Apr 5, 2020 at 4:38 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> There is already something in equivclass.c that would almost do what
>> we want here: exprs_known_equal() would tell us whether the partkeys
>> can be found in the same eclass, without having to generate data
>> structures along the way. The current implementation is not watertight
>> because it doesn't check opclass semantics, but that consideration
>> can be bolted on readily enough. So that leads me to something like
>> the attached.
> I have some concern about we only check non-nullable partexprs. Is it
> possible that two nullable partexprs come from the same EC? I tried to
> give an example but failed.
Currently the EC infrastructure doesn't really cope with outer join
equijoins. They are not treated as producing true equivalences,
so I think that the case you're worried about can't occur (which is why
I didn't code for it). I have hopes of being able to incorporate outer
joins into the EC logic in a less squishy way in the future, by making
the representation of Vars distinguish explicitly between
value-before-outer-join and value-after-outer-join, after which we could
make bulletproof assertions about what is equal to what, even with outer
joins in the mix. If that works out it might produce a cleaner answer
in this area too.
TBH, now that I have had some exposure to the partitionwise join
matching logic I don't much like any of it. I feel like it's doing
about the same job as ECs, but in an unprincipled and not very
efficient manner. Right now is no time to redesign it, of course,
but maybe at some point we could do that. (I did experiment with
removing all the rest of have_partkey_equi_join() and having it
*only* ask exprs_known_equal() about equivalences, which is more or
less what I'm envisioning here. That caused some of the existing
regression tests to fail, so there's something that the idea isn't
covering. I didn't dig any further at the time, and in particular
failed to check whether the problems were specifically about outer
joins, which'd be unsurprising given the above.)
Anyway, this work has missed the window for v13, so we've got plenty
of time to think about it.
regards, tom lane