On 5/8/2018 9:58 AM, root23 wrote: > In case of frange query how do we specify the Must clause ?
Looking at how frange works, I'm pretty sure that all queries with frange are going to be effectively single-clause. So you don't need to specify MUST -- it's implied. > the reason we are using frange instead of the normal syntax is that we need > to add a cost to this clause. Since this will return a lot of documents, we > want to calculate at the end of all the clauses. That is why we are using > frange with a cost of 200. Ah, you want it to be a postFilter, which frange supports, but the standard lucene parser doesn't. FYI, to actually achieve a postFilter, you need to set cache=false in addition to a cost of 100 or higher. It's not possible to cache postFilters because of how they work, so they must be uncached. Which also means you don't need to worry about using NOW/DAY date rounding. See the "Expensive Filters" section on this blog post for an example with frange that includes cache=false and cost=200: https://lucidworks.com/2012/02/10/advanced-filter-caching-in-solr/ The requirement for cache=false is not mentioned on the blog post above. It was this post that alerted me to that requirement: https://lucidworks.com/2017/11/27/caching-and-filters-and-post-filters/ > We have near real time requirements and that is the reason we are using 500 > ms in the autosoft commit. > We have autowarmCount="60%" for filter cache. What is the size of the filterCache? Chances are very good that this translates to a fairly high autowarmCount, and that it is making your automatic soft commits take far longer than 500 milliseconds. If the warming is slow, then you're not getting the half-second latency anyway, so configuring it is at best a waste of resources, and at worst a big performance problem. Achieving NRT indexing requires turning off all warming. To see how long it took to warm the searcher on the last commit, go to the admin UI. Choose your index from the dropdown, click on Plugins/Stats, click on CORE, then open the "searcher" entry. In the displayed information will be "warmupTime", with a value in milliseconds. I'm betting that this number will be larger than 500. If I'm wrongabout that, then you might not have anything to worry about. You can also see warmup times for the individual caches with the CACHE entry in Plugins/Stats. Typically it's filterCache that takes the longest. https://www.dropbox.com/s/izwad4h2vl1z752/solr-filtercache-stats.png?dl=0 A long time ago, I was having issues on my servers with commits taking a minute or more. I discovered that it was autowarming on the filterCache that caused it. So I reduced autowarmCount on that cache. Eventually I got to an autowarmCount of *four*. Not 4 percent, I am literally doing warming from the top 4 cache entries. Even with the count that low, commits still sometimes take 10 seconds or more, and the vast majority of that time is spent executing those four warming queries from the filterCache. Thanks, Shawn
