[
https://issues.apache.org/jira/browse/LUCENE-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15808257#comment-15808257
]
Michael McCandless commented on LUCENE-7588:
--------------------------------------------
Hmm, but in {{testRandom}} we seem to always sort by {{id}} (a unique field for
each document) for each search?
So, regardless of using a single thread for the search, or doing the map/reduce
w/ N threads and merging with {{TopDocs.merge}}, the result order should have
been identical, I think?
> A parallel DrillSideways implementation
> ---------------------------------------
>
> Key: LUCENE-7588
> URL: https://issues.apache.org/jira/browse/LUCENE-7588
> Project: Lucene - Core
> Issue Type: Improvement
> Affects Versions: master (7.0), 6.3.1
> Reporter: Emmanuel Keller
> Priority: Minor
> Labels: facet, faceting
> Fix For: master (7.0), 6.4
>
> Attachments: LUCENE-7588.patch, lucene-7588-test.patch
>
>
> Currently DrillSideways implementation is based on the single threaded
> IndexSearcher.search(Query query, Collector results).
> On large document set, the single threaded collection can be really slow.
> The ParallelDrillSideways implementation could:
> 1. Use the CollectionManager based method IndexSearcher.search(Query query,
> CollectorManager collectorManager) to get the benefits of multithreading on
> index segments,
> 2. Compute each DrillSideway subquery on a single thread.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
