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.

simlaudato / asterixdb

Automatically exported from code.google.com/p/asterixdb

0 stars 0 forks source link

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. #925

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago

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.

Original issue reported on code.google.com by kiss...@gmail.com on 10 Aug 2015 at 8:03

GoogleCodeExporter commented 9 years ago

I just captured Yingyi's question here:

------------
In theory, a returned primary key could be deleted because secondary index
search does not lock anything...
Is the overhead mostly from pin/un-pin BF pages?
------------

Original comment by kiss...@gmail.com on 10 Aug 2015 at 4:15

GoogleCodeExporter commented 9 years ago

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.

Original comment by kiss...@gmail.com on 10 Aug 2015 at 4:27