FWIW, since it seemed like there was at least one bug here (and possibly
more), I filed
https://issues.apache.org/jira/browse/SOLR-8171
On 10/6/15, 3:58 PM, "Jeff Wartes" wrote:
>
>I dug far enough yesterday to find the GET_DOCSET, but not far enough to
>find why. Thanks, a little context is
Jeff,
so far tests routine is reasonable, but since we count a facet, we expect
that filtering by one of this values is used at the following requests. I
suppose the next request with fq=popularity:1 or so might show reuse that
cached filter, but it's just my speculation.
On Tue, Oct 6, 2015 at 3:
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:
: 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=true
: &facet.field=popularity&facet.mincount=0&facet.limit=-1
: This still causes
this insert is caused by
https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/search/SolrIndexSearcher.java#L1505
off-top thought:
showItems are useless, because now it looks like
- item_name:foo:org.apache.solr.search.SortedIntDocSet@2e1fbd46
Shouldn't it b
I backed up a bit. I took the stock solr download and did this:
solr-5.3.1>$ bin/solr -e techproducts
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&
On Thu, 2015-10-01 at 22:31 +, Jeff Wartes wrote:
> It still inserts if I address the core directly and use distrib=false.
It is quite strange that is is triggered with the direct access. If that
can be reproduced in test, it looks like a performance optimization to
be done.
Anyway, operating
On 01/10/2015 23:31, Jeff Wartes wrote:
It still inserts if I address the core directly and use distrib=false.
I’ve got a few collections sharing the same config, so it’s surprisingly
annoying to
change solrconfig.xml right now, but it seemed pretty clear the query is
the thing being cached, sin
It still inserts if I address the core directly and use distrib=false.
I’ve got a few collections sharing the same config, so it’s surprisingly
annoying to
change solrconfig.xml right now, but it seemed pretty clear the query is
the thing being cached, since
the cache size only changes when the qu
hm..
This option was useful for introspecting cache content
https://wiki.apache.org/solr/SolrCaching#showItems It might help you to
find-out a cause.
I'm still blaming distributed requests, it expained here
https://cwiki.apache.org/confluence/display/solr/Faceting#Faceting-Over-RequestParameters
eg
No change, still shows an insert per-request. As does a simplified request
with only the facet params
"&facet.field=city&facet=true"
It’s definitely facet related though, facet=false eliminates the insert.
On 10/1/15, 1:50 PM, "Mikhail Khludnev" wrote:
>what if you set f.city.facet.limit=-1
what if you set f.city.facet.limit=-1 ?
On Thu, Oct 1, 2015 at 7:43 PM, Jeff Wartes wrote:
>
> I’m doing some fairly simple facet queries in a two-shard 5.3 SolrCloud
> index on fields like this:
>
> docValues="true”/>
>
> that look something like this:
> q=...&fl=id,score&facet.field=city&face
I’m doing some fairly simple facet queries in a two-shard 5.3 SolrCloud
index on fields like this:
13 matches
Mail list logo
