Re: FilterQueries with NRT
You can experiment with the backdoor NRT filters: - replace COLOR:Red to {!parent which='COLOR:Red' v=''} - add *NoOpRegenerator **into perSegFilter* *- **monitor cache stats. * On Fri, May 11, 2018 at 10:46 PM, root23wrote: > Hi all, > We have a requirement for NRT search. Our autosoft commit time is set to > 500 > ms(i know its low.But that's another story). We use filter queries > extensively for most of our queries. > > But i am trying to understand how filter query caching works with NRT. > Now as i understand we use fq for queries which are commonly used across > most of our searches, so that they get cached and will be reused across > multiple queries. However the cache is only good for the life time of a > indexSearcher. > And as we do a new soft commit a new searcher will open and it will creates > its own cache and if we have autowarmcount set to 0, its essentially will > start with an empty filter cache. > Now since the autosoft commit time is 500 ms, in theory we are openeing a > searcher every 0.5 second. > > So in this case does it make even sense to cache anything, if we are gona > throw it away 0.5 second later and start again. > Does adding stuff to fq gives us anything in this particular scenario. > > > > -- > Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html > -- Sincerely yours Mikhail Khludnev
Re: FilterQueries with NRT
bq. does it make even sense to cache anything In a word, "no". Now only would I set the cache entry size to zero, I'd form my filer queries with {!cache=false}... There's no particular point in computing the entire cache entry in this case, possibly even with a cost=101. See: http://yonik.com/advanced-filter-caching-in-solr/. And I'll spare you the rant about 500 ms being unreasonable as you seem to already get that ;) Best, Erick On Fri, May 11, 2018 at 12:46 PM, root23wrote: > Hi all, > We have a requirement for NRT search. Our autosoft commit time is set to 500 > ms(i know its low.But that's another story). We use filter queries > extensively for most of our queries. > > But i am trying to understand how filter query caching works with NRT. > Now as i understand we use fq for queries which are commonly used across > most of our searches, so that they get cached and will be reused across > multiple queries. However the cache is only good for the life time of a > indexSearcher. > And as we do a new soft commit a new searcher will open and it will creates > its own cache and if we have autowarmcount set to 0, its essentially will > start with an empty filter cache. > Now since the autosoft commit time is 500 ms, in theory we are openeing a > searcher every 0.5 second. > > So in this case does it make even sense to cache anything, if we are gona > throw it away 0.5 second later and start again. > Does adding stuff to fq gives us anything in this particular scenario. > > > > -- > Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
FilterQueries with NRT
Hi all, We have a requirement for NRT search. Our autosoft commit time is set to 500 ms(i know its low.But that's another story). We use filter queries extensively for most of our queries. But i am trying to understand how filter query caching works with NRT. Now as i understand we use fq for queries which are commonly used across most of our searches, so that they get cached and will be reused across multiple queries. However the cache is only good for the life time of a indexSearcher. And as we do a new soft commit a new searcher will open and it will creates its own cache and if we have autowarmcount set to 0, its essentially will start with an empty filter cache. Now since the autosoft commit time is 500 ms, in theory we are openeing a searcher every 0.5 second. So in this case does it make even sense to cache anything, if we are gona throw it away 0.5 second later and start again. Does adding stuff to fq gives us anything in this particular scenario. -- Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html