[ https://issues.apache.org/jira/browse/LUCENE-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979276#action_12979276 ]
Earwin Burrfoot commented on LUCENE-2840: ----------------------------------------- bq. But doesn't that mean that an app w/ rare queries but each query is massive fails to use all available concurrency? Yes. But that's not my case. And likely not someone else's. I think if you want to be super-generic, it's better to defer exact threading to the user, instead of doing a one-size-fits-all solution. Else you risk conjuring another ConcurrentMergeScheduler. While we're at it, we can throw in some sample implementation, which can satisfy some of the users, but not everyone. > Multi-Threading in IndexSearcher (after removal of MultiSearcher and > ParallelMultiSearcher) > ------------------------------------------------------------------------------------------- > > Key: LUCENE-2840 > URL: https://issues.apache.org/jira/browse/LUCENE-2840 > Project: Lucene - Java > Issue Type: Sub-task > Components: Search > Reporter: Uwe Schindler > Priority: Minor > Fix For: 4.0 > > > Spin-off from parent issue: > {quote} > We should discuss about how many threads should be spawned. If you have an > index with many segments, even small ones, I think only the larger segments > should be separate threads, all others should be handled sequentially. So > maybe add a maxThreads cound, then sort the IndexReaders by maxDoc and then > only spawn maxThreads-1 threads for the bigger readers and then one > additional thread for the rest? > {quote} -- 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org