Sujith created CARBONDATA-527:
---------------------------------
Summary: Greater than/less-than/Like filters optimization for dictionary columns
Key: CARBONDATA-527
URL:
https://issues.apache.org/jira/browse/CARBONDATA-527 Project: CarbonData
Issue Type: Improvement
Reporter: Sujith
Current design
In greater than/less-than/Like filters, system first iterates each row present in the dictionary cache for identifying valid filter actual members by applying the filter expression , once evaluation done system will hold the list of identified valid filter actual member values(String), now in next step again system will look up the dictionary cache in order to identify the dictionary surrogate values of the identified members. this look up is an additional cost to our system even though the look up methodology is an binary search in dictionary cache.
Proposed design/solution:
Identify the dictionary surrogate values in filter expression evaluation step itself when actual dictionary values will be scanned for identifying valid filter members .
Keep a dictionary counter variable which will be increased when system iterates through the dictionary cache in order to retrieve each actual member stored in dictionary cache , after this system will evaluate each row against the filter expression to identify whether its a valid filter member or not, while doing this process itself counter value can be taken as valid selected dictionary value since the actual member values and its dictionary values will be kept in same order in dictionary cache as the iteration order.
thus it will eliminate the further dictionary look up step which is required to retrieve the dictionary surrogate value against identified actual valid filter member. this can also increase significantly the filter query performance of such filter queries which require expression evaluation to identify it the filter members by looking up dictionary cache, like greater than/less-than/Like filters .
Note : this optimization is applicable for dictionary columns.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)