-
Notifications
You must be signed in to change notification settings - Fork 220
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
optimizer: filter scan rule #834
Comments
maybe related: #795? But it's a known issue and if you want to fix that, please submit a pull request, thanks! |
It seems like that the filter is true by default, instead of null. So the solution may be like this in #795? risinglight/src/binder/table.rs Lines 60 to 70 in cd03496
|
github-merge-queue bot
pushed a commit
that referenced
this issue
Apr 12, 2024
related to #794 #834 , add some new rules and change scan's default filter to true(this make it match with the "filter-scan" rule) Signed-off-by: kysshsy <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
risinglight/src/planner/rules/range.rs
Lines 88 to 100 in 0e4a846
Here's my understanding: When there are predicates on primary key, we should push them down to the storage layer. Is that right?
But it seems not to work when I execute statements like
select pk from t where pk > 1
. And thefilter
passed toscan
function is alwaysNone
. It looks like these:Maybe the
true
in"(scan ?table ?columns true)"
should be replaced tonull
? Because it seems to work if I change it.The text was updated successfully, but these errors were encountered: