Fix the reverse scan null predicate missing issue for JOIN case #2606
Conversation
| joinClauses.addAll(innerAccessPath.otherExprs); | ||
| ArrayList<AbstractExpression> otherExprs = new ArrayList<AbstractExpression>(); | ||
| // PLEASE do not update the "innerAccessPath.otherExprs", it may be reused | ||
| // for other path evaluation on the other outer side join. |
There was a problem hiding this comment.
I don't understand this comment. Can you identify the method where the innerAccessPath.otherExprs element needs to be reused? Can you identify a specific case where we want to extract a single-TVE expression into innerExpr and also keep it available in innerAccessPath.otherExprs?
Is the idea that we extract all single-TVE expressions as just a first pass to get conditions that MIGHT be indexable on the one specific side, and we don't care yet about the TVEs' tables because we will check that we are on the correct side (for that table) later? I could believe that, but, for the sake of query performance, I would want some confirmation that the final plan does not leave behind a completely redundant join condition that was already enforced by the child scan (either as an index-covered predicate or as a scan post-predicate).
I am suspicious that this SEEMs to specifically solve a join-of-reverse-scan-with-null case.
Does this mean that a reverse scan could still have a null-handling bug in the non-join case?
Or can you explain how this join mis-handling was specifically causing a null handling bug --
was it really a more general bug, and this reverse scan null case just happened to be the one reproducer we found -- one of many possible symptoms of a missing filter?
Fix the reverse scan null predicate missing issue for JOIN case
No description provided.