[
https://issues.apache.org/jira/browse/LUCENE-5092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13884320#comment-13884320
]
Michael McCandless commented on LUCENE-5092:
--------------------------------------------
On quick glance this looks like a lot of infrastructure to add, merely to
support block joins.
What's wrong with simply leaving block joins as requiring the concrete
FixedBitSet? The typical usage of block joins will require one instance of
FixedBitSet per "joined" table, per segment; the RAM required (vs. a compressed
bit set impl) should be trivial e.g. compared to the "typical" bit-set caching
Solr does.
> 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
