fix: fix NotEq case in anticipation of non-literals #1260
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The code as written fails when the "other" [min, max] interval has size greater than 1.
Call the left-hand-side's interval: `[lmin, lmax]` and the right-hand-side's interval: `[rmin,
rmax]`. The current expression is:
(lmin == rmin) && (rmin == lmax)
||
(lmin == rmax) && (rmax == lmax)
By transitivity, in either conjunction, lmin == lmax. That means the column has a single known
value: lmin (equivalently: lmax).
If the right-hand-side is only ever literals or expressions thereof, its interval is always `[x,
x]`. In that case, this expression is tantamount to: is the column constant and equal to `x`?
If the right-hand-side is either another column or some non-deterministic expression, the interval
could be, for example: `[10, 11]`. If the column is known to be the constant value `10` (i.e. its
min and max are 10), we cannot prune this chunk! The rows where the right-hand-side is 11 would
satisfy the inequality.
I'm also open to: `(lmin == lmax) && (lmin == rmin)` with a comment indicating that, because we only
have literals, rmin is necessarily equal to rmax and thus rmin _is_ the, known, right-hand-side
value.
Contributor
|
one hand side in this transformation is literal, the other can be other expression. I was basically trying to prune a != b but maybe that's not that useful |
robert3005
reviewed
Nov 8, 2024
robert3005
approved these changes
Nov 8, 2024
Contributor
|
One thing I didn't add is simple evaluation tests. We should have a simple table to make sure the filtered table is what we expect. This can happen independently of this pr. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The code as written fails when the "other" [min, max] interval has size greater than 1.
Call the left-hand-side's interval:
[lmin, lmax]and the right-hand-side's interval:[rmin, rmax]. The current expression is:By transitivity, in either conjunction, lmin == lmax. That means the column has a single known value: lmin (equivalently: lmax).
If the right-hand-side is only ever literals or expressions thereof, its interval is always
[x, x]. In that case, this expression is tantamount to: is the column constant and equal tox?If the right-hand-side is either another column or some non-deterministic expression, the interval could be, for example:
[10, 11]. If the column is known to be the constant value10(i.e. its min and max are 10), we cannot prune this chunk! The rows where the right-hand-side is 11 would satisfy the inequality.I'm also open to:
(lmin == lmax) && (lmin == rmin)with a comment indicating that, because we only have literals, rmin is necessarily equal to rmax and thus rmin is the, known, right-hand-side value.