[ 
https://issues.apache.org/jira/browse/LUCENE-5092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13884364#comment-13884364
 ] 

Paul Elschot commented on LUCENE-5092:
--------------------------------------

bq. On quick glance this looks like a lot of infrastructure to add, merely to 
support block joins.

It is bigger than necessary because it has both FixedBitSet and FixedBitSetDBI, 
and I hope these can be merged somehow.
The bit index that FixedBitSet uses for good nextDoc() performance got in my 
way when trying to implement advanceToJustBefore().
That is why I added FixedBitSetDBI, see LUCENE-5416.

bq. What's wrong with simply leaving block joins as requiring the concrete 
FixedBitSet?

Two things, but first let me agree that saving RAM is not a concern.

The first one is increased speed for larger document blocks.
See http://people.apache.org/~jpountz/doc_id_sets.html, AFAICT that means at 
least 500-1000 docs per block for now.

The other one is to allow future implementations. Some time ago when Filter was 
based on Java's BitSet  (LUCENE-584 ...),  TermDocsEnum (iirc) and Filter and 
Scorer were more or less independent classes. Just look at the class hierarchy 
that we have now.

It might turn out that DocBlocksIterator as a marker interface is better than 
directly inheriting from DocIdSetIterator. Direct inheritance works for now.

Btw. the test cases in the join module really helped, thanks.


> join: don't expect all filters to be FixedBitSet instances
> ----------------------------------------------------------
>
>                 Key: LUCENE-5092
>                 URL: https://issues.apache.org/jira/browse/LUCENE-5092
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: modules/join
>            Reporter: Adrien Grand
>            Assignee: Adrien Grand
>            Priority: Minor
>         Attachments: LUCENE-5092.patch
>
>
> The join module throws exceptions when the parents filter isn't a 
> FixedBitSet. The reason is that the join module relies on prevSetBit to find 
> the first child document given a parent ID.
> As suggested by Uwe and Paul Elschot on LUCENE-5081, we could fix it by 
> exposing methods in the iterators to iterate backwards. When the join modules 
> gets an iterator which isn't able to iterate backwards, it would just need to 
> dump its content into another DocIdSet that supports backward iteration, 
> FixedBitSet for example.



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

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

Reply via email to