As per my understanding caches are flushed every time when add new document to collection (we do soft commit at every 1 sec to make newly added document available for search). Due to which it is not effectively uses cache and hence it slow every time in our case. -----Original Message----- From: Toke Eskildsen [mailto:t...@statsbiblioteket.dk] Sent: 19 August 2015 12:16 To: solr-user@lucene.apache.org Subject: Re: Performance issue with FILTER QUERY
On Wed, 2015-08-19 at 05:55 +0000, Maulin Rathod wrote: > SLOW WITH FILTER QUERY (takes more than 1 second) > ============================================ > > q=+recipient_id:(4042) AND project_id:(332) AND resource_id:(13332247 > 13332245 13332243 13332241 13332239) AND entity_type:(2) AND > -action_id:(20 32) ==> This returns 5 records > fq=+action_status:(0) AND is_active:(true) ==> This Filter Query > returns 9432252 records The fq is evaluated independently of the q: For the fq a bitset is allocated, filled and stored in cache. Then the q is evaluated and the two bitsets are merged. Next time you use the same fq, it should be cached (if you have caching enabled) and be a lot faster. Also, if you ran your two tests right after each other, the second one benefits from disk caching. If you had executed them in reverse order, the q+fq might have been the fastest one. - Toke Eskildsen, State and University Library, Denmark
