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 your "extremely high
facet.limi
ne with an explaination for this? This is counterintuitive, well to me at
least.
Thanks,
Markus
-Original message-
> From:Chris Hostetter
> Sent: Tuesday 6th December 2016 1:47
> To: solr-user@lucene.apache.org
> Subject: RE: Solr seems to reserve facet.limit results
>
>
>
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 constr
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 -- s
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
13:01
> To: solr_user lucene_apache
> 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 high
> > facet.limit are three to five times slower com
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 facet.limit=20
