I dug far enough yesterday to find the GET_DOCSET, but not far enough to find why. Thanks, a little context is really helpful sometimes.
So, starting with an empty filterCache... http://localhost:8983/solr/techproducts/select?q=name:foo&rows=1&facet=true &facet.field=popularity New values: lookups: 0, hits: 0, inserts: 1, size: 1 So for the reasons you explained, "inserts" is incremented for this new search http://localhost:8983/solr/techproducts/select?q=name:boo&rows=1&facet=true &facet.field=popularity New values: inserts: lookups: 0, hits: 0, inserts 2, size: 2 Another new search, another new insert. No "lookups" though, so how does it know name:boo wasn’t cached? http://localhost:8983/solr/techproducts/select?q=name:boo&rows=1&facet=true &facet.field=popularity New values: inserts: lookups: 1, hits: 1, inserts: 2, size: 2 But it clearly does know - when I repeat the search, I get both a lookup and a hit. (and no insert) So is this just a bug in the stats reporting, perhaps? When I first started looking at this, it was in a solrcloud cluster, and one interesting thing about that cluster is that it was configured with the queryResultCache turned off, so let’s repeat the above experiment without the queryResultCache. (I’m just commenting it out in the techproducts config for this run.) Starting with an empty filterCache... http://localhost:8983/solr/techproducts/select?q=name:foo&rows=1&facet=true &facet.field=popularity New values: lookups: 0, hits: 0, inserts: 1, size: 1 Same as before... http://localhost:8983/solr/techproducts/select?q=name:boo&rows=1&facet=true &facet.field=popularity New values: inserts: lookups: 0, hits: 0, inserts 2, size: 2 Same as before... http://localhost:8983/solr/techproducts/select?q=name:boo&rows=1&facet=true &facet.field=popularity New values: inserts: lookups: 0, hits: 0, inserts 3, size: 2 No cache hit! We get an insert instead, but it’s already in there, so the size doesn’t change. So disabling the queryResultCache apparently causes facet queries to be unable to use the filterCache? I’m increasingly thinking that different use cases need different filterCaches, rather than try to bundle every explicit or unexpected use-case under one cache with one size and one regenerator. On 10/6/15, 2:45 PM, "Chris Hostetter" <hossman_luc...@fucit.org> wrote: >: So, no SolrCloud, default example config, about as basic as you get. I >: didn’t even bother indexing any docs. Then I issued this query: >: >: >http://localhost:8983/solr/techproducts/select?q=name:foo&rows=1&facet=tru >e >: &facet.field=popularity&facet.mincount=0&facet.limit=-1 > >: This still causes an insert into the filterCache. > >the faceting component is a type of operation that indicates in the >QueryCommand that it needs to GET_DOCSET for the set of all documents >matching the query (independent of pagination) -- the point of this >DocSet >is so the faceting logic can then compute the intersection of the set of >all matching documents with the set of documents matching each facet >constraint. the cached DocSet will be re-used both within the context >of the current request, and in future facet requests over the >same query+filters. > >: The only real difference I’m noticing vs my solrcloud collection is that >: repeating the query increments cache lookups and hits. It’s still odd >: though, because issuing new distinct queries causes a reported insert, >but >: not a lookup, so the cache hit ratio is always exactly 1. > >i'm not following what you are saying at all ... can you give some >concrete examples (ie: "starting with an empty cache i do this request, >then i see these cache stats, then i do this identical/different query >and >then the cache stats look like this...") > > > >-Hoss >http://www.lucidworks.com/
