[
https://issues.apache.org/jira/browse/LUCENE-2447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12864602#action_12864602
]
Yonik Seeley edited comment on LUCENE-2447 at 5/5/10 8:37 PM:
--------------------------------------------------------------
I think I'm leaning toward Earwin's thinking... MultiSearcher seems to be
mostly behavior and almost no state. Push a little more in that direction and
you have a lot of flexibility. Perhaps allow the CachedDfSource to be
specified, don't copy the Searchable[] array, and all of a sudden it's as light
weight as a String.
edit: actually, I just realized that CachedDfSource isn't even maintained
state... it already is really light weight. Adding the ability to specify an
Executor gets you 99% there.
was (Author: [email protected]):
I think I'm leaning toward Earwin's thinking... MultiSearcher seems to be
mostly behavior and almost no state. Push a little more in that direction and
you have a lot of flexibility. Perhaps allow the CachedDfSource to be
specified, don't copy the Searchable[] array, and all of a sudden it's as light
weight as a String.
> Add support for subsets of searchables inside a
> MultiSearcher/ParallelMultiSearcher instance's methods at runtime
> -----------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-2447
> URL: https://issues.apache.org/jira/browse/LUCENE-2447
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Affects Versions: 3.0.1
> Environment: Irrelevant
> Reporter: Edward Drapkin
> Priority: Minor
> Attachments: LUCENE-2447-predicate.patch, LUCENE-2447.patch
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> Here's the situation: We have a site with a fair few amount of indexes that
> we're using MultiSearcher/ParallelMultiSearcher for, but the users can select
> an arbitrary permutation of indexes to search. For example (contrived, but
> illustratory): the site has indexes numbered 1 - 10; user A wants to search
> in all 10; user B wants to search indexes 1, 2 and 3, user C wants to search
> even-numbered indexes. From Lucene 3.0.1, the only way to do this is to
> continually instantiate a new MultiSearcher based on every permutation of
> indexes that a user wants, which is not ideal at all.
> What I've done is add a new parameter to all methods in MultiSearcher that
> use the searchables array (docFreq, search, rewrite and
> createDocFrequencyMap), a Set<Searchable> which is checked for isEmpty() and
> contains() for every iteration over the searchables[]. The actual logic has
> been moved into these methods and the old methods have become overloads that
> pass a Collections.emptySet() into those methods, so I do not expect there to
> be a very noticeable performance impact as a result of this modification, if
> it's measurable at all.
> I didn't modify the test for MultiSearcher very much, just enough to
> illustrate the that subsetting of the search results works, since no other
> logic has changed. If I need to do more for the testing, let me know and
> I'll do it.
> I've attached the patches for MultiSearcher.java, ParallelMultiSearcher.java
> and TestMultiSearcher.java.
--
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]
