[
https://issues.apache.org/jira/browse/SOLR-5674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher updated SOLR-5674:
-------------------------------
Component/s: (was: contrib - Clustering)
search
Labels: QueryComponent (was: QueryComponet rows)
Summary: The rows improvement for QueryComponent (was: The rows
improvement for QueryComponet)
> The rows improvement for QueryComponent
> ---------------------------------------
>
> Key: SOLR-5674
> URL: https://issues.apache.org/jira/browse/SOLR-5674
> Project: Solr
> Issue Type: Bug
> Components: search
> Affects Versions: 4.3.1, 4.5.1, 4.6
> Environment: JVM7
> Reporter: Raintung Li
> Labels: QueryComponent
> Attachments: SOLR-5674.txt
>
>
> For solr Rows issues:
> 1. Solr don't provide get full results API, usually customer will set the
> rows is Integer.maxvalue try to get the full results that cause the other
> issue. OOM issue in solr
> :SOLR-5661(https://issues.apache.org/jira/browse/SOLR-5661)
> How about open the API for rows=-1? That means return full results. Sometimes
> the result count will every biggest that will cause the heap OOM, but usually
> we can suggest the customer to make sure the result really small that can
> call this API. Actually we don't want to make the second call to get full
> results. For one is call API get total number, for two get the result set
> rows into total number.
> 2. A litter improve, because every shard node return results has been
> ordered. Add first shard list into the PriorityQueue that don't need compare
> again only filter the same unique id.
> 3. Create the PriorityQueue after check all shard return sizes, that can
> avoid the unnecessary memory cost especially biggest rows.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
