On 4/12/2018 1:46 AM, LOPEZ-CORTES Mariano-ext wrote:
In our search application we have one facet filter (Status)

Each status value corresponds to multiple values in the Solr database

Example : Status : Initialized --> status in solr =  11I, 12I, 13I, 14I, ...

On status value click, search is re-fired with fq filter:

fq: status:(11I OR 12I OR 13I ....)

This was very very inefficient. Filter query response time was longer than same 
search without filter!

How many different status values are you including in that query?  And how many unique values are there in the status field for the entire index?

Echoing what Emir said:  If the numbers are large, it's going to be slow.  But once that filter is run successfully, it should be cached until the next time you commit changes to your index and open a new searcher, or there are enough different filters executed that this entry is pushed out of the cache.

Having sufficient memory for your operating system to effectively cache your index data can speed up ALL queries.  How much memory do you have in the server?  How much memory have you allocated to Solr on that system?  Is there software other than Solr installed on the server?  How much disk space do all the Solr indexes on that server consume?  How many documents are represented by that disk space?

Back in late February, I discussed this with you when you were wanting query times below one second.

We have changed status value in Solr database for corresponding to visual 
filter values. In consequence, there is no OR in the fq filter.
The performance is better now.

This seems to say that you've made a change that improved your situation.  But reading what you wrote, I cannot tell what that change was.

If you're running at least version 4.10, you could use the terms query parser instead of a search clause with OR separators.  In addition to better performance, this query parser doesn't have the maxBooleanClauses limit.



Reply via email to