wangning has posted comments on this change. ( http://gerrit.cloudera.org:8080/16903 )
Change subject: KUDU-1644 use range partition info for pruning ...................................................................... Patch Set 3: (3 comments) http://gerrit.cloudera.org:8080/#/c/16903/1//COMMIT_MSG Commit Message: http://gerrit.cloudera.org:8080/#/c/16903/1//COMMIT_MSG@9 PS1, Line 9: When pruning in-list predicate values, range partition can also be taken > I can see this being particularly useful if range partitioning is defined p We don't have heavy scenarios on range-schema based inList query. So I would do a small scale benchmark about this patch. http://gerrit.cloudera.org:8080/#/c/16903/1/src/kudu/common/scan_spec-test.cc File src/kudu/common/scan_spec-test.cc: http://gerrit.cloudera.org:8080/#/c/16903/1/src/kudu/common/scan_spec-test.cc@584 PS1, Line 584: AddInPredicate<int8_t>(&spec, "a", { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }); : AddInPredicate<int8_t>(&spec, "b", { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }); > So far, we have good test coverage for the cases where 'a' is pruned. Could I just realize that range key can be differ from hash key. I adjusted some code for it. Thx for point out. http://gerrit.cloudera.org:8080/#/c/16903/1/src/kudu/common/scan_spec-test.cc@601 PS1, Line 601: b > Should this be "b"? Ah, yes, that explains why the previous patched result is so weird. -- To view, visit http://gerrit.cloudera.org:8080/16903 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: kudu Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: I3f14f543cffd44f090026f344c9b06af13ea2e10 Gerrit-Change-Number: 16903 Gerrit-PatchSet: 3 Gerrit-Owner: wangning <[email protected]> Gerrit-Reviewer: Andrew Wong <[email protected]> Gerrit-Reviewer: Kudu Jenkins (120) Gerrit-Reviewer: wangning <[email protected]> Gerrit-Comment-Date: Wed, 06 Jan 2021 09:38:05 +0000 Gerrit-HasComments: Yes
