[ https://issues.apache.org/jira/browse/SOLR-5674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Shalin Shekhar Mangar reassigned SOLR-5674: ------------------------------------------- Assignee: Shalin Shekhar Mangar > 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 > Assignee: Shalin Shekhar Mangar > 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