Markus Jelsma wrote:
> I tried the overrequest ratio/count and set them to 1.0/0 . Odd enough,
> with these settings high facet.limit and extremely high facet.limit are
> both up to twice as slow as with 1.5/10 settings.
Not sure if it is the right explanation for
with an explaination for this? This is counterintuitive, well to me at
least.
Thanks,
Markus
-Original message-
> From:Chris Hostetter <hossman_luc...@fucit.org>
> Sent: Tuesday 6th December 2016 1:47
> To: solr-user@lucene.apache.org
> Subject: RE: Solr seems to reserve f
On Mon, 2016-12-05 at 17:47 -0700, Chris Hostetter wrote:
> : One simple solution, in my case would be, now just thinking of it,
> : run the query with no facets and no rows, get the numFound, and set
> : that as facet.limit for the actual query.
>
> ...that assumes that the number of facet
I think what you're seeing might be a result of the overrequesting done
in phase #1 of a distriuted facet query.
The purpose of overrequesting is to mitigate the possibility of a
constraint which should be in the topN for the collection as a whole, but
just outside the topN on every shard --
On Fri, 2016-12-02 at 12:17 +, Markus Jelsma wrote:
> I have not considered streaming as i am still completely unfamiliar
> with it and i don't yet know what problems it can solve.
Standard faceting requires all nodes to produce their version of the
full result and send it as one chunk, which
Sent: Friday 2nd December 2016 13:01
> To: solr_user lucene_apache <solr-user@lucene.apache.org>
> Subject: Re: Solr seems to reserve facet.limit results
>
> On Fri, 2016-12-02 at 11:21 +, Markus Jelsma wrote:
> > Despite the number of actual results, queries with a very hi
On Fri, 2016-12-02 at 11:21 +, Markus Jelsma wrote:
> Despite the number of actual results, queries with a very high
> facet.limit are three to five times slower compared to much lower
> values. For example, i have a query that returns roughly 19.000 facet
> results. Queries with
Hi - in some cases we want all facets values and counts for a given query, it
can be 10k or even 10m but also just one thousand.
Despite the number of actual results, queries with a very high facet.limit are
three to five times slower compared to much lower values. For example, i have a
query