[jira] [Updated] (LUCENE-5052) bitset codec for off heap filters

["Nina Gracheva (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/LUCENE-5052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nina Gracheva updated LUCENE-5052:
----------------------------------

    Attachment: LUCENE-5052.patch

This is adopted version of BitSetCodec. It uses BlockTermsWriter/Reader infrastructure to build posting format with custom posting writer/reader and standard terms writer/reader. TODO use  Long.numberOfTrailingZeros() in advance() and nexdoc()

> bitset codec for off heap filters
> ---------------------------------
>
>                 Key: LUCENE-5052
>                 URL: https://issues.apache.org/jira/browse/LUCENE-5052
>             Project: Lucene - Core
>          Issue Type: New Feature
>          Components: core/codecs
>            Reporter: Mikhail Khludnev
>              Labels: features
>             Fix For: 5.0
>
>         Attachments: LUCENE-5052.patch, bitsetcodec.zip
>
>
> Colleagues,
> When we filter we don’t care any of scoring factors i.e. norms, positions, tf, but it should be fast. The obvious way to handle this is to decode postings list and cache it in heap (CachingWrappingFilter, Solr’s DocSet). Both of consuming a heap and decoding as well are expensive. 
> Let’s write a posting list as a bitset, if df is greater than segment's maxdocs/8  (what about skiplists? and overall performance?). 
> Beside of the codec implementation, the trickiest part to me is to design API for this. How we can let the app know that a term query don’t need to be cached in heap, but can be held as an mmaped bitset?
> WDYT?  



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org