[
https://issues.apache.org/jira/browse/SOLR-5595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13859611#comment-13859611
]
Hoss Man commented on SOLR-5595:
--------------------------------
The initial change that would be needed to explore any of these ideas is
addressing the issue of the query result cache. It seems like adding a
FieldDoc[] onto the DocSlice should be fairly straight forward, even when
dealing with the subset and cache window stuff -- but for non trivial sorts it
would likely result in a significant change to the memory foot print, which
could be very annoying if you aren't using distributed sorting.
my off the cuff suggestion would be:
* change the code to include the FieldDoc (sort values) in the (cached)
DocSlices
* add an explicit option to disable caching of the sort values (for single node
users)
* make distributed searching fail hard if that explicit option is set
** fail hard on SolrCore init in cloud mode
** fail hard at request time if it's an older style "shards=..." distributed
request.
> Distributed Sort: potential performance improvements & code readabiliity
> ------------------------------------------------------------------------
>
> Key: SOLR-5595
> URL: https://issues.apache.org/jira/browse/SOLR-5595
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
>
> A lot of the work solr currently does for dealing with distributed sorting
> was built based on older limitations in Lucene that no longer exist. There
> are opportunities to simplify the code significantly, which should result in
> a speed up -- the biggest blocker at this point is some caching related
> questions.
> I'll post my specific thoughts in a comment
> (This is inspired by some things I noticed working on SOLR-5463 - I didn't
> want to convolute that issue with these performance improvement ideas which
> could be dealt with separately)
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
