You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
select Title, ECTS = any (select ECTS from Courses c2
where Lecturer =123) someE‘ual
from Courses c1
The result column someEqual can have the values TRUE, FALSE, and NULL (i.e.,
unknown). Accordingly, some care is needed to implement the mark join correctly, as we
will discuss in Section 5. But the great benefit is that we now translate arbitrary exists/not
exists/unique/quantified-comparison queries into a join construct and eventually, after
further optimizations, obtain an efficient evaluation strategy.
This seems like desirable behavior, and consistent with the general direction of subquery de-correlation.
This limitation also seems to be documented in null_aware_anti_join.slt, and currently returns wrong results:
I've started splitting up my PR because its too big IMO and its a pain to handle, first part is #22981 which is mostly the SLT tests I had, documenting some of the current behavior.
Activity
AdamGS commentedon Apr 1, 2026
take
neilconway commentedon Apr 5, 2026
Cool! I'm also interested in this area.
AdamGS commentedon Apr 5, 2026
I have a branch locally that somewhat works, it needs some more work and thinking
AdamGS commentedon Jun 16, 2026
I've started splitting up my PR because its too big IMO and its a pain to handle, first part is #22981 which is mostly the SLT tests I had, documenting some of the current behavior.
feat: Support null aware hash mark-joins (apache#21585)