[
https://issues.apache.org/jira/browse/ASTERIXDB-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16213678#comment-16213678
]
ASF subversion and git services commented on ASTERIXDB-2128:
------------------------------------------------------------
Commit 9782f8a295595efad74fd494960cd2680f3e7c42 in asterixdb's branch
refs/heads/master from [~luochen01]
[ https://git-wip-us.apache.org/repos/asf?p=asterixdb.git;h=9782f8a ]
[ASTERIXDB-2128] Fix bloomfilter during index search
- user model changes: no
- storage format changes: no
- interface changes: no
Details:
- The current use of bloomfilter during search is completely wrong
(including primary index point lookups, secondary index search with
deleted btrees). We call BTree.search before bloomfilter check,
which renders bloomfilter completely useless. This patch fixes this
serious problem.
Change-Id: I90ab0d0b2da0028e0ec3cfa94d21881318293ff7
Reviewed-on: https://asterix-gerrit.ics.uci.edu/2069
Reviewed-by: abdullah alamoudi <bamou...@gmail.com>
Sonar-Qube: Jenkins <jenk...@fulliautomatix.ics.uci.edu>
Tested-by: Jenkins <jenk...@fulliautomatix.ics.uci.edu>
Contrib: Jenkins <jenk...@fulliautomatix.ics.uci.edu>
Integration-Tests: Jenkins <jenk...@fulliautomatix.ics.uci.edu>
> Bloom Filter for LSMBTree is totally useless
> --------------------------------------------
>
> Key: ASTERIXDB-2128
> URL: https://issues.apache.org/jira/browse/ASTERIXDB-2128
> Project: Apache AsterixDB
> Issue Type: Bug
> Components: IDX - Indexes, STO - Storage
> Reporter: Chen Luo
> Assignee: Chen Luo
>
> We use bloom filters on primary index (as LSMBTree) to skip unnecessary pk
> lookups on some disk components. The idea is that if the bloom filter reports
> false on some pk, we totally skip searching that disk component.
> However, in our current complicated BTree/LSMBTree software stack, the bloom
> filter is completely useless (in terms of saving I/Os). Take a look at
> LSMBTreePointSearchCursor. At line 74, we first call
> btreeAccessors[i].search(rangeCursors[i], predicate), and then call
> BloomFilterAwareBTreePointSearchCursor.hasNext() which performs bloom filter
> check. However, the call sequence is wrong. Actually,
> btreeAccessors[i].search has already searched the primary key against the
> BTree, from the root down to the leaf, rendering bloom filter completely
> useless in this case.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
