-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
simplify segment pruning #8790
simplify segment pruning #8790
Conversation
bd13922
to
853cdc9
Compare
Codecov Report
@@ Coverage Diff @@
## master #8790 +/- ##
============================================
- Coverage 69.63% 69.63% -0.01%
+ Complexity 4621 4619 -2
============================================
Files 1736 1733 -3
Lines 91203 91188 -15
Branches 13632 13630 -2
============================================
- Hits 63513 63497 -16
- Misses 23269 23272 +3
+ Partials 4421 4419 -2
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
LGTM |
85e485e
to
51231f2
Compare
51231f2
to
0e7298a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Segment pruning feels over-engineered:
DataSchemaSegmentPruner
andValidSegmentPruner
are just one liners which can be applied when necessaryColumnValueSegmentPruner
andSelectionQuerySegmentPruner
are mutually exclusive so never both need to run, and these cases can be identified easily by examining theQueryContext
This leads to inefficiencies like
This PR removes the two trivial pruners and applies them inline the
SegmentPrunerService
before the two remaining pruners. It adds a new method to identify based on the query context whether the pruner should run at all.