Re: FilterQueries with NRT

2018-05-12 Thread Mikhail Khludnev
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, root23  wrote:

> 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

2018-05-11 Thread Erick Erickson
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, root23  wrote:
> 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

2018-05-11 Thread root23
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