Yeah i meant filter-cache, thanks. It seemed that the particular field (cityname) was using a keywordtokenizer (which doens't show at the front) which is why i missed it i guess :-S. This means the term field is tokenized so termEnums-apporach is used. This results in about 10.000 inserts on facet.field=cityname on a cold searcher, which matches the nr of different terms in that field. At least that explains that.
So if I understand correctly if I use that same field in a FQ-param, say fq=cityname:amsterdam and amsterdam is a term of field cityname, than the FQ-query can utilize the cached 'query': cityname:amsterdam which is already put into the filtercache by the query facet.field=cityname right? The thing that I still don't get is why my filtercache starts to have evictions although it's size is 16.000+. This shouldn't be happing given that: I currently only use faceting on cityname and use this field on FQ as well, as already said (which adds +/- 10000 items to the filtercache, given that faceting and fq share cached items). Moreover i use FQ on about 2500 different fields (named _ddp*), but only check to see if a value exists by doing for example: fq=_ddp1234:[* TO *]. I sometimes add them together like so: fq=_ddp1234:[* TO *] &fq=_ddp2345:[* TO *]. But never like so: fq=_ddp1234:[* TO *] +_ddp2345:[* TO *]. Which means each _ddp*-field is only added once to the filtercache. Wouldn't this mean that at a maximum I can only have 12500 items in the filtercache? Still my filtercache starts to have evictions although it's size is 16.000+. What am I missing here? Geert-Jan hossman wrote: > > > : ..fq=country:france > : > : do these queries share cached items in the fieldcache? (in this example: > : country:france) or do they somehow live as seperate entities in the > cache? > : The latter would explain my fieldcache having evictions at the moment. > > FieldCache can't have evicitions. it's a really low level "cache" where > the key is field name and the value is an array containing a value for > every document (you cna think of it as an inverted-inverted-index) that > Lucene maintains directly. items are never removed they just get garbage > collected when the IndexReader is no longer used. It's primarily for > sorting, but the SimpleFacets code also leveragies it for facets in some > cases -- Solr has no way of showing you what's in the FieldCache, because > Lucene doesn't expose any inspection APIs to query it (it's a heisenberg > cache .. once you ask if something is in it, it's in it) > > are you refering to the "filterCache" ? > > filterCache contains records whose key is a "query" and whose value is a > DocSet (an unordered collection of all docs matching a query) ... it's > used whenever you use an "fq" param, for faceting on some fields (when the > TermEnum method is used, a filterCache entry is added for each term > tested), and even for some sorted queries if the > <useFilterForSortedQuery/> config option is set to true. > > the easiest way to know whether your faceting is using the FieldCache is > to start your server cold (no newSearcher warming) and then send it a > simple query with a single facet.field. depending on the query, you might > get 0 or 1 entries in the filterCache if SimpleFacets is using the > FieldCache -- but if it's using the TermEnums, and generating a DocSet per > term, you'llsee *lots* of inserts into the filterCache. > > > > -Hoss > > -- View this message in context: http://www.nabble.com/quickie%3A-do-facetfields-use-same-cached-items-in-field-cache-as-FQ-param--tf4609795.html#a13169935 Sent from the Solr - User mailing list archive at Nabble.com.
