Mailing-List: contact dev-help@asterixdb.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@asterixdb.incubator.apache.org
MIME-Version: 1.0
Reply-To: <codesite-noreply@google.com>
References: 
 <1-12833755227771893259-10344353308763431914-asterixdb=googlecode.com@googlecode.com>
 <0-12833755227771893259-10344353308763431914-asterixdb=googlecode.com@googlecode.com>
In-Reply-To: 
 <1-12833755227771893259-10344353308763431914-asterixdb=googlecode.com@googlecode.com>
Message-ID: 
 <2-12833755227771893259-10344353308763431914-asterixdb=googlecode.com@googlecode.com>
Date: Mon, 10 Aug 2015 16:27:31 +0000
Subject: Re: Issue 925 in asterixdb: Bloomfilter search preceded by primary
 index lookup after secondary index search is nothing but overhead since all
 primary keys returned from secondary indexes are all valid and exist.
From: asterixdb@googlecode.com
To: dev@asterixdb.incubator.apache.org
Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes


Comment #2 on issue 925 by kiss...@gmail.com: Bloomfilter search preceded  
by primary index lookup after secondary index search is nothing but  
overhead since all primary keys returned from secondary indexes are all  
valid and exist.
https://code.google.com/p/asterixdb/issues/detail?id=925

That's correct. I missed that.
But still the possibility to see the deleted secondary key from the  
secondary index in reality could be very low.
We need to profile the pros and cons of using bloomfilter in this situation.
Probably, pin/unpin will be the major cost if the page is not in the  
buffercache already plus the overhead of going through buffer cache's  
critical section. Other than that, computing hash value will be the next  
major cost.


-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings