[
https://issues.apache.org/jira/browse/HIVE-9188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14268573#comment-14268573
]
Owen O'Malley commented on HIVE-9188:
-------------------------------------
[~prasanth_j] Ok, I thought that you said that you were going to have bloom
filters at row group, stripe, and file level. I agree completely that ORC
should only have bloom filters at the row group level.
Having the bloom filter as a separate stream means the reader does *far* less
IO. It will still go through the code that merges adjacent ranges together into
a single read. So if you need all of the indexes and bloom filters for all of
the columns the reader should read them in a single IO operation. On the other
hand, if it doesn't need any bloom filter it shouldn't have to load the extra
mb of data it doesn't need.
> BloomFilter in ORC row group index
> ----------------------------------
>
> Key: HIVE-9188
> URL: https://issues.apache.org/jira/browse/HIVE-9188
> Project: Hive
> Issue Type: New Feature
> Components: File Formats
> Affects Versions: 0.15.0
> Reporter: Prasanth Jayachandran
> Assignee: Prasanth Jayachandran
> Labels: orcfile
> Attachments: HIVE-9188.1.patch, HIVE-9188.2.patch, HIVE-9188.3.patch,
> HIVE-9188.4.patch
>
>
> BloomFilters are well known probabilistic data structure for set membership
> checking. We can use bloom filters in ORC index for better row group pruning.
> Currently, ORC row group index uses min/max statistics to eliminate row
> groups (stripes as well) that do not satisfy predicate condition specified in
> the query. But in some cases, the efficiency of min/max based elimination is
> not optimal (unsorted columns with wide range of entries). Bloom filters can
> be an effective and efficient alternative for row group/split elimination for
> point queries or queries with IN clause.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
