[
https://issues.apache.org/jira/browse/LUCENE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12558115#action_12558115
]
Eks Dev commented on LUCENE-584:
--------------------------------
hmm, in order to have fast and/or operations we need to know the type of the
underlaying object in Filter, and sometimes we must use iterators (e.g. case
where one Filter/DocSetId is int list and another Hash bit set ). I guess,
knowing type of DocIdSet is the trick to pool.
Default implementation of ChainedFilter (there is also BooleanFilter somewhere
in contrib, I like it more) should be using iterator (like scorers), and at a
few key points checking if(first instance of SomeInstanceOfDocIdSet && second
SomeInstanceOfDocIdSet) first.doFastOR/AND(second);
something in that direction looks reasonable to me for ChainedFilter
If it proves to be really better to have it around. I am still of an opinion
that it would be better to integrate DocIdSet into BooleanQuery as a clause,
somehow, that would be some kind of ConstantBoolean(MUST/SHOULD/NOT)Clause,
much cleaner from design/usability point of view, even at some minor penalty in
performance (anyhow, you can always combine filters before you enter scorers)
but you are right that is another issue... let us stop polluting this issue :)
> Decouple Filter from BitSet
> ---------------------------
>
> Key: LUCENE-584
> URL: https://issues.apache.org/jira/browse/LUCENE-584
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Affects Versions: 2.0.1
> Reporter: Peter Schäfer
> Assignee: Michael Busch
> Priority: Minor
> Fix For: 2.4
>
> Attachments: bench-diff.txt, bench-diff.txt,
> ContribQueries20080111.patch, lucene-584-take2.patch,
> lucene-584-take3-part1.patch, lucene-584-take3-part2.patch,
> lucene-584-take4-part1.patch, lucene-584-take4-part2.patch, lucene-584.patch,
> Matcher-20070905-2default.patch, Matcher-20070905-3core.patch,
> Matcher-20071122-1ground.patch, Some Matchers.zip
>
>
> {code}
> package org.apache.lucene.search;
> public abstract class Filter implements java.io.Serializable
> {
> public abstract AbstractBitSet bits(IndexReader reader) throws IOException;
> }
> public interface AbstractBitSet
> {
> public boolean get(int index);
> }
> {code}
> It would be useful if the method =Filter.bits()= returned an abstract
> interface, instead of =java.util.BitSet=.
> Use case: there is a very large index, and, depending on the user's
> privileges, only a small portion of the index is actually visible.
> Sparsely populated =java.util.BitSet=s are not efficient and waste lots of
> memory. It would be desirable to have an alternative BitSet implementation
> with smaller memory footprint.
> Though it _is_ possibly to derive classes from =java.util.BitSet=, it was
> obviously not designed for that purpose.
> That's why I propose to use an interface instead. The default implementation
> could still delegate to =java.util.BitSet=.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
