chema has a parent document, two child documents(siblings), and
a grandchild document. I am using the JSON API .
Product -> Item-> Price
|
\/
ProductCategory
I created my schema to represent a multi-store, and multi-customer setup.
I am looking for multi-select facets from *eac
t; > "sort": { "t": "asc" },
> > > "start": "2018-05-02T17:00:00.000Z",
> > > "end": "2020-11-16T21:00:00.000Z",
> > > &q
: "+1HOUR"
> > "limit": 1
> > }
> > }
> > }
> > }
> > }
> >
> > On Thu, Dec 3, 2020 at 12:59 PM Arturas Mazeika wrote:
> >
> > > Hi Michael,
> > >
> On Thu, Dec 3, 2020 at 12:59 PM Arturas Mazeika wrote:
>
> > Hi Michael,
> >
> > Thanks for helping me to figure this out.
> >
> > If I fire:
> >
> > {
> > "query" : "*:*",
> > "limit" : 0,
> >
1:00:00.000Z",
"gap": "+1HOUR"
"limit": 1
}
}
}
}
}
On Thu, Dec 3, 2020 at 12:59 PM Arturas Mazeika wrote:
> Hi Michael,
>
> Thanks for helping me to figure
Hi Michael,
Thanks for helping me to figure this out.
If I fire:
{
"query" : "*:*",
"limit" : 0,
"facet": {
"aip": { "query": "cfname2:aip", }
}
}
I get
"response": { "num
quot;, "prefix":"3" },
> "a4": { "query": "cfname2:4" },
> "a5": { "query": "cfname2:5" },
> "a6": { "query": "cfname2:6" },
>
> "tt": {
>
: "cfname2:5" },
"a6": { "query": "cfname2:6" },
"tt": {
"t_buckets": {
"type": "range",
"field": "t",
"sort": { "t": "asc" },
"start": "2018-05-02T17:00:00.000Z",
"end": "2020-11-16T21:00:00.000Z",
"gap": "+1HOUR"
}
}
}
}
Single (not nested facets separately on individual queries as well as for
range) work in flying colors.
Cheers,
Arturas
Ah, ok! The Jira issue mentioned in the mail thread you cited above
has some further discussion/detail. (I don't think adding a "{!terms}"
query filter would necessarily work ... it'd need to be a group of
facets of type "query", sorted client-side ... unless
Thanks Michael,
I agree - JSON Facets is a better candidate for the functionality I'm
looking for. In my case specifically though, I think I'm pegged to
traditional facets because I also want to use the "terms" local params
support that doesn't have a native equival
Answering a slightly different question perhaps, but you can
definitely do this with the "JSON Facet" API, where there's much
cleaner separation between different facets (and output is assigned to
arbitrary keys).
Michael
On Tue, Nov 17, 2020 at 9:36 AM Jason Gerlowski wrote:
>
Hi all,
Is it possible to have multiple facets on the same field with
different parameters (mincount, limit, prefix, etc.) on each?
The ref-guide describes these per-facet parameters as being settable
on a "per-field basis" with syntax of
"f..facet." [1]. But I wasn't
ntaineering tour, ...
> >> * We have hundreds of customers that want to facet their searches to that
> >> content types but often with distinct combinations of categories, i.e.
> >> customer A wants his facet "tours" to only count hiking tours, customer B
> &
which
>> themselves may be categorized: A tour may be a hiking tour, a
>> mountaineering tour, ...
>> * We have hundreds of customers that want to facet their searches to that
>> content types but often with distinct combinations of categories, i.e.
>> customer A wants h
s" to only count hiking tours, customer B
> only mountaineering tours, customer C a combination of both, etc
> * We use "query" facets as each facet request will be build dynamically (it
> is not feasible to aggregate certain categories and add them as an
> additional solr sch
searches to that
content types but often with distinct combinations of categories, i.e.
customer A wants his facet "tours" to only count hiking tours, customer B
only mountaineering tours, customer C a combination of both, etc
* We use "query" facets as each facet request will be b
e in the response, the ability to nest
stats and subfacets, etc.) ... just thinking out loud at the moment
...
On Wed, Oct 28, 2020 at 9:17 AM Erick Erickson wrote:
>
> This really sounds like an XY problem. The whole point of facets is
> to count the number of documents that have a value in som
This really sounds like an XY problem. The whole point of facets is
to count the number of documents that have a value in some
number of buckets. So trying to stop your facet query as soon
as it matches a hit for the first time seems like an odd thing to do.
So what’s the “X”? In other words
Hi,
I use json facets of type 'query'. As these queries are pretty slow and I'm
only interested in whether there is a match or not, I'd like to restrict
the query execution similar to the standard facetting (like with the
facet.exists parameter). My simplified query looks som
uot;id":"ta-0-NCT04372953",
"therapeuticareaname":"Premature Birth",
"text_prefixauto":"Premature Birth",
"text_suggest":[
"Premature Birth"
],
"diseaseareas":[
t;:[
{
"id":"ta-0-NCT04372953",
"therapeuticareaname":"Premature Birth",
"text_prefixauto":"Premature Birth",
"text_suggest":[
"Premature Birth"
],
"disea
spot.com/
>
>
> On Tue, May 5, 2020 at 5:54 PM Revas wrote:
>
> > Hi joel, No, we have not, we have softCommit requirement of 2 secs.
> >
> > On Tue, May 5, 2020 at 3:31 PM Joel Bernstein wrote:
> >
> > > Have you configured static warming queries for the f
check out the videos on this website TROO.TUBE don't be such a
sheep/zombie/loser/NPC. Much love!
https://troo.tube/videos/watch/aaa64864-52ee-4201-922f-41300032f219
On Wed, May 13, 2020 at 7:56 AM Saurabh Sharma
wrote:
>
> Hi All,
>
> I am trying to use two sorting criteria wit
Hi All,
I am trying to use two sorting criteria with json facets but found that
only one of them is working and other one is not getting honoured.
sort:{ sortingScore:desc , x:desc} , Here only sortingScore is being used
by solr and parameter x is ignored . Is there any way using which I can use
lucky))
> > > &start=0
> > > &rows=0
> > > &fq=channelId:(2 1 3 78 34 35 7 72)
> > > &fq=date:([* TO 2020-05-12T03:59:59.999Z])
> > > &facet=true
> > > &facet.field=channelId
> > > &f.channelId.facet.limit=10
;facet.field=channelId
> > &f.channelId.facet.limit=10
> > &f.channelId.facet.mincount=1
> > &hl=false
> > &fl=id
> > &wt=json
> > &sort=random_123456 desc
> >
> > The issue is that I only want 100 random resul
nelId
> &f.channelId.facet.limit=10
> &f.channelId.facet.mincount=1
> &hl=false
> &fl=id
> &wt=json
> &sort=random_123456 desc
>
> The issue is that I only want 100 random results. Sure, I could limit
> the results returned to the first 100 by sp
cet.limit=10
&f.channelId.facet.mincount=1
&hl=false
&fl=id
&wt=json
&sort=random_123456 desc
The issue is that I only want 100 random results. Sure, I could limit
the results returned to the first 100 by specifying &rows=100, but the
facets would match the query totals and
/faceting.html#tagging-and-excluding-filters
On Mon, May 11, 2020 at 3:36 PM David Lukowski
wrote:
> I'm looking for a way if possible to run a query with random results, where
> I limit the number of results I want back, yet still have the facets
> accurately reflect the results I'm se
I'm looking for a way if possible to run a query with random results, where
I limit the number of results I want back, yet still have the facets
accurately reflect the results I'm searching.
When I run a search I use a filter query to randomize the results based on
a modulo of a random
Bernstein
http://joelsolr.blogspot.com/
On Tue, May 5, 2020 at 5:54 PM Revas wrote:
> Hi joel, No, we have not, we have softCommit requirement of 2 secs.
>
> On Tue, May 5, 2020 at 3:31 PM Joel Bernstein wrote:
>
> > Have you configured static warming queries for the face
Hi joel, No, we have not, we have softCommit requirement of 2 secs.
On Tue, May 5, 2020 at 3:31 PM Joel Bernstein wrote:
> Have you configured static warming queries for the facets? This will warm
> the cache structures for the facet fields. You just want to make sure you
> commits a
Have you configured static warming queries for the facets? This will warm
the cache structures for the facet fields. You just want to make sure you
commits are spaced far enough apart that the warming completes before a new
searcher starts warming.
Joel Bernstein
http://joelsolr.blogspot.com
Hi Erick, Thanks for the explanation and advise. With facet queries, does
doc Values help at all ?
1) indexed=true, docValues=true => all facets
2)
- indexed=true , docValues=true => only for subfacets
- inexed=true, docValues=false=> facet query
- docValues=true, inde
DocValues should help when faceting over fields, i.e. facet.field=blah.
I would expect docValues to help with sub facets and, but don’t know
the code well enough to say definitely one way or the other.
The empirical approach would be to set “uninvertible=true” (Solr 7.6) and
turn docValues off
Hi Erick, You are correct, we have only about 1.8M documents so far and
turning on the indexing on the facet fields helped improve the timings of
the facet query a lot which has (sub facets and facet queries). So does
docValues help at all for sub facets and facet query, our tests
revealed further
020, at 11:51 PM, Revas wrote:
>
> We have faceting fields that have been defined as indexed=false,
> stored=false and docValues=true
>
> However we use a lot of subfacets using json facets and facet ranges
> using facet.queries. We see that after every soft-commit our perf
We have faceting fields that have been defined as indexed=false,
stored=false and docValues=true
However we use a lot of subfacets using json facets and facet ranges
using facet.queries. We see that after every soft-commit our performance
worsens and performs ideal between commits
how is that
I don't have any particular idea. Probably it's worth to start from
learning debugQuery=true output. There are caveats:
- it takes a while
- it's worth to limit shards to a few ones
- it used to produce incorrect json, and worked in only in wt=xml
At least it let to sneak something about the longes
Promoting my question
Artur Rudenko
-Original Message-
From: Rudenko, Artur
Sent: Wednesday, February 12, 2020 10:33 PM
To: solr-user@lucene.apache.org
Subject: Slow quires and facets
Hello everyone,
I'm am currently investigating a performance issue in our environment:
20M
Hello everyone,
I'm am currently investigating a performance issue in our environment:
20M large PARENT documents and 800M nested small CHILD documents.
The system inserts about 400K PARENT documents and 16M CHILD documents per day.
(Currently we stopped the calls insertion to investigate the perf
Hello, Kumar.
I don't know. 3 / 84 ratio seems reasonable. The only unknown part of the
equation was that {!simpleFilter}. Anyway, profiler/sampler might get exact
answer.
On Fri, Jan 24, 2020 at 8:55 AM kumar gaurav wrote:
> HI Mikhail
>
> Can you please see above debug log and help ?
>
> Than
HI Mikhail
Can you please see above debug log and help ?
Thanks
On Thu, Jan 23, 2020 at 12:05 AM kumar gaurav wrote:
> Also
>
> its not looks like box is slow . because for following query prepare time
> is 3 ms but facet time is 84ms on the same box .Don't know why prepare time
> was huge fo
Also
its not looks like box is slow . because for following query prepare time
is 3 ms but facet time is 84ms on the same box .Don't know why prepare time
was huge for that example :( .
debug:
{
- rawquerystring:
"{!parent tag=top which=$pq filters=$child.fq score=max v=$cq}",
- queryst
't comment on it.
> Parsing queries took in millis: - time: 261, usually prepare for query
> takes a moment. I suspect the box is really slow per se or encounter heavy
> load.
> And then facets took about 6 times more - facet_module: { - time: 1122,
> that a reasonable rat
Initial request refers unknown (to me) query parser {!simpleFilter, I
can't comment on it.
Parsing queries took in millis: - time: 261, usually prepare for query
takes a moment. I suspect the box is really slow per se or encounter heavy
load.
And then facets took about 6 times
; > {
> > - productsCount: "uniqueBlock(_root_)"
> > },
> > },
> > - size_refine:
> > {
> > - domain:
> > {
> > - excludeTags: "rassortment,top,top2,top3,t
ne1}) filter({!term f=color_refine v=$qcolor_refine2})
>> > qcolor_refine1=Blue
>> > qcolor_refine2=Other clrs
>> > cq=+{!simpleFilter v=docType:sku}
>> > pq=docType:(product)
>> > facet=true
>> > facet.mincount=1
>> > facet.limit=-
gt; qcolor_refine1=Blue
>> > qcolor_refine2=Other clrs
>> > cq=+{!simpleFilter v=docType:sku}
>> > pq=docType:(product)
>> > facet=true
>> > facet.mincount=1
>> > facet.limit=-1
>> > facet.missing=false
>> > json.facet= {c
refine:{
> > domain:{
> > filter:["{!filters param=$child.fq excludeTags=rcolor_refine
> > v=$sq}","{!child of=$pq filters=$fq}docType:(product)"]
> >},
> > type:terms,
> > field:color_refine,
> > limit:-1,
> > facet:{productsCount:"uni
}docType:(product)"]
>},
> type:terms,
> field:color_refine,
> limit:-1,
> facet:{productsCount:"uniqueBlock(_root_)"}}}
>
> schema :-
> multiValued="true" docValues="true"/>
>
> i have observed that json facets are
lters param=$child.fq excludeTags=rcolor_refine
v=$sq}","{!child of=$pq filters=$fq}docType:(product)"]
},
type:terms,
field:color_refine,
limit:-1,
facet:{productsCount:"uniqueBlock(_root_)"}}}
schema :-
i have observed that json facets are slow . It is taking much t
/joelsolr.blogspot.com/
> >>>>
> >>>>
> >>>> On Thu, Dec 12, 2019 at 6:28 AM Mel Mason <
> mel.ma...@bodleian.ox.ac.uk>
> >>>> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> I&
olr/blob/master/solr/core/src/java/org/apache/solr/search/facet/FacetRange.java#L255
It looks like during the change to JSONFacet the range facets have been
restricted to only allow Trie or PointField fields. Is this likely to
be
fixed in future updates, or were there problems with using
DateRan
acet system - a quick google turns up several other people with
>> the
>> >> same problem. When using JSONFacet I get problems with this line of
>> >> code:
>> >>
>> >>
>> https://github.com/apache/lucene-solr/blob/master/solr/core/src/j
e with the
> >> same problem. When using JSONFacet I get problems with this line of
> >> code:
> >>
> >>
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/search/facet/FacetRange.java#L255
> >>
> >> It look
oks like during the change to JSONFacet the range facets have been
restricted to only allow Trie or PointField fields. Is this likely to be
fixed in future updates, or were there problems with using
DateRangeFields? I could use the old parameter facet system, but there
are features in JSONFac
ems with this line of
> code:
>
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/search/facet/FacetRange.java#L255
>
> It looks like during the change to JSONFacet the range facets have been
> restricted to only allow Trie or PointField fields. Is t
src/java/org/apache/solr/search/facet/FacetRange.java#L255
>
> It looks like during the change to JSONFacet the range facets have been
> restricted to only allow Trie or PointField fields. Is this likely to be
> fixed in future updates, or were there problems with using
> DateRangeFields? I
is line of
code:
https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/search/facet/FacetRange.java#L255
It looks like during the change to JSONFacet the range facets have been
restricted to only allow Trie or PointField fields. Is this likely to be
fixed in future u
ld for
hour of the day
-Original Message-
From: Erick Erickson
Sent: Wednesday, June 19, 2019 1:34 PM
To: solr-user@lucene.apache.org
Subject: Re: creating date facets
*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.
There are two approaches I m
You might find this useful. If makes creating time series aggregations a
little easier. It uses JSON facets under the covers and is very fast.
https://lucene.apache.org/solr/guide/7_6/stream-source-reference.html#timeseries
Joel Bernstein
http://joelsolr.blogspot.com/
On Wed, Jun 19, 2019 at 1
19, 2019, at 10:25 AM, Nightingale, Jonathan A (US)
> wrote:
>
> Hi all,
> I'm trying to have a date field automatically generate some facets of itself,
> like hour of the day and hour of the week as examples, when its stored. I was
> looking at this tutorial and it
Hi all,
I'm trying to have a date field automatically generate some facets of itself,
like hour of the day and hour of the week as examples, when its stored. I was
looking at this tutorial and it deemed to almost do what I wanted
https://nathanfriend.io/2017/06/26/smart-date-searching
This is old. Still worth replying, as sometimes somebody might stumble across
the same problem.
Well I achieved this rather simply by using facet.pivot. If you define your
facet.pivot as “n_cellered_diseaseExact,id” you will get in return the data
structure containing pivot list of all disease
But in the
meantime, unfortunately your only option is to use the NamedList
structures directly to retrieve the stat value.
Thanks for bringing it to our attention.
Best,
Jason
On Fri, Mar 8, 2019 at 4:42 AM Andrea Gazzarini wrote:
>
> Good morning guys, I have a questions about Solrj and JSON
Good morning guys, I have a questions about Solrj and JSON facets.
I'm using Solr 7.7.1 and I'm sending a request like this:
json.facet={x:'max(iterationTimestamp)'}
where "iterationTimestamp" is a solr.DatePointField. The JSON response
correctly includes wha
Yes, all the three options (copy fields, using dynamic fields and the
SortableTextField) are feasible. Since I am on the 7.5.0 version of Solr, I
will go ahead with the SortableTextField option.
Thank you team!!
On Fri, Dec 7, 2018 at 8:46 PM Alexandre Rafalovitch
wrote:
> If you are on the la
If you are on the latest Solr (7.3+), try switching from TextField to
SortableTextField in your string_ci definition above.
That type implicitly uses docValues and should return original text
for faceting purposes, while still allowing analyzers.
Regards,
Alex.
On Thu, 6 Dec 2018 at 08:26, Rit
you could change your indexer to index the values to a dynamic field *_ci
for each of the facets.
ie, your facet is organization. index to the string field, and also index
it to the dynamic organization_ci field
but there will not be a short cut way of doing this in the schema itself
On Fri
Fields need to be copied. You can shorten the schema with using wildcards
*.
On Fri, Dec 7, 2018 at 9:03 AM Ritesh Kumar
wrote:
> Yes, it can be used.
> But, what if I have other such facets on different other fields. Use of
> copyField will require me to create a dedicated copy field
Yes, it can be used.
But, what if I have other such facets on different other fields. Use of
copyField will require me to create a dedicated copy field for each such
facet.
I want to know if there is any other option where I do not have to add
multiple copy fields.
On Thu, Dec 6, 2018 at 7:06 PM
Hello, Ritesh.
It's obviously done with copyField.
On Thu, Dec 6, 2018 at 4:26 PM Ritesh Kumar
wrote:
> Hello team,
>
> I am trying to prepare facet on a field of type string. The facet data will
> be shown according to the user's query on this very field.
>
> required="false" multiValued="fal
Hello team,
I am trying to prepare facet on a field of type string. The facet data will
be shown according to the user's query on this very field.
As this field is of type string, it works fine with case sensitive query. I
want to be able to query on this field irrespective of the case.
I tri
Hi all.
I’m trying to do some analysis on our data. Specifically hoping to see the
top and bottom x% of terms in a particular field. I’d prefer to not loop
through all terms by way of an updated offset if I can help it.
Is there any cool way to request in the facet query a subset based on a
dynam
>
> Hi all,
>
> We’re running a SolrCloud 7.1 instance in our service and I’ve come across at
> a disagreement when trying to find out the different values a field has:
>
> Using the JSON facets API with unique():
> 3385
>
> Using the JSON facets API with te
Hi all,
We’re running a SolrCloud 7.1 instance in our service and I’ve come across at a
disagreement when trying to find out the different values a field has:
Using the JSON facets API with unique():
3385
Using the JSON facets API with terms:
3388
Using the stats component:
countDistinct
ocess of upgrading from version 6.3.0 to version 7.2.1
>> and have found something that doesn't seem to work with the json facets any
>> more. The query is below
>>
>> /select?q=*:*&wt=xml&indent=off&rows=0&fq=groupid:(4572
>> 4573)+AN
ing from version 6.3.0 to version 7.2.1 and
> have found something that doesn't seem to work with the json facets any
> more. The query is below
>
> /select?q=*:*&wt=xml&indent=off&rows=0&fq=groupid:(4572
> 4573)+AND+gmttimestamp:[2018-08-05T00:00:00Z+TO+2018-
Hi all,
We are in the process of upgrading from version 6.3.0 to version 7.2.1 and
have found something that doesn't seem to work with the json facets any
more. The query is below
/select?q=*:*&wt=xml&indent=off&rows=0&fq=groupid:(4572
4573)+AND+gmttimestamp:[2018-08-05
/faceting.html#Faceting-TaggingandExcludingFilters>).
It works as I expect, the facet result are being build correctly with
correct facet results, but the response from Solr is very slow and
becasue of that I cannot deploy this on production (about 3.5 seconds).
I'm going to trim out your actual query.
Th
Dear Solr User,
I develop an online shop which has possibility to search for products and
filter the results. I've used Solr as an engine to search through our shop
offer.
Currently I am trying to rebuild the products filter so it will use Solr search
facet result to show its attributes. I am
On 2/8/2018 5:36 AM, LOPEZ-CORTES Mariano-ext wrote:
> We are just 1 field "status" in facets with a cardinality of 93.
>
> We realize that increasing memory will work. But, you think it's necessary?
>
> Thanks in advance.
2GB for 27 million docs seems a little bit s
First thing I'd try is setting docValues="true". You must blow away your
entire index, like I'm -rf data And reindex.
On Feb 8, 2018 04:37, "LOPEZ-CORTES Mariano-ext" <
mariano.lopez-cortes-...@pole-emploi.fr> wrote:
> We are just 1 field "status
We are just 1 field "status" in facets with a cardinality of 93.
We realize that increasing memory will work. But, you think it's necessary?
Thanks in advance.
-Message d'origine-
De : Zisis T. [mailto:zist...@runbox.com]
Envoyé : jeudi 8 février 2018
I believe that things like the following will affect faceting memory
requirements
-> how many fields do you facet on
-> what is the cardinality of each one of them
-> What is you QPS rate
but 2GB for 27M documents seems too low. Did you try to increase the memory
on Solr's JVM?
--
Sent from:
We are experimentig memory problems regarding facets filters (OutOfMemory java
heap).
If we disable facets, it works ok.
Our infrastructure :
3 nodes Solr 2048 MB RAM
3 nodes Zookeeper 1024 MB RAM
Size : 27 millions of documents
Any ideas ?
Thanks in advance !
Hi,
I have a surprising performance issue with the 'unique' function in a json
facet
My setup holds large amount of docs (~1B), despite this large number I only
facet on a small result set of a query, only a few docs. The query itself
returns as fast as expected, but when I try to do a unique cou
Facing errors on using groups and facets
These queries work fine -
http://localhost:8983/solr/urls/select?q=*:*&rows=0&facet=true&facet.field=city_id
http://localhost:8983/solr/urls/select?q=*:*&rows=0&facet=true&facet.field=city_id&group=true&group.field=locality_
John Davis wrote:
> 100M unique values might be across all docs, and unless the faceting
> implementation is really naive I cannot see how that can come into play
> when the query matches a fraction of those.
Solr simple string faceting uses an int-array to hold counts for the different
terms in
w even when the query matches hundreds of docs.
> >>
> >> On Mon, Oct 23, 2017 at 6:53 AM, alessandro.benedetti <
> a.benede...@sease.io>
> >> wrote:
> >>
> >>> Hi John,
> >>> first of all, I may state the obvious, but have you tr
6:53 AM, alessandro.benedetti
>> wrote:
>>
>>> Hi John,
>>> first of all, I may state the obvious, but have you tried docValues ?
>>>
>>> Apart from that a friend of mine ( Diego Ceccarelli) was discussing a
>>> probabilistic implementation simi
"blog_post": "solr",
"is_root_document": true,
"_childDocuments_": [{
"id": "comment-1",
"title": "awesome work",
"comment": "this was a great read&qu
gt; Apart from that a friend of mine ( Diego Ceccarelli) was discussing a
>> probabilistic implementation similar to the hyperloglog[1] to approximate
>> facets counting.
>> I didn't have time to take a look in details / implement anything yet.
>> But it is on our To Do list :)
all, I may state the obvious, but have you tried docValues ?
>
> Apart from that a friend of mine ( Diego Ceccarelli) was discussing a
> probabilistic implementation similar to the hyperloglog[1] to approximate
> facets counting.
> I didn't have time to take a look in details
Hi John,
first of all, I may state the obvious, but have you tried docValues ?
Apart from that a friend of mine ( Diego Ceccarelli) was discussing a
probabilistic implementation similar to the hyperloglog[1] to approximate
facets counting.
I didn't have time to take a look in details / impl
Hi Yonik,
Any update on sampling based facets. The current faceting is really slow
for fields with high cardinality even with method=uif. Or are there
alternative work-arounds to only look at N docs when computing facets?
On Fri, Nov 4, 2016 at 4:43 PM, Yonik Seeley wrote:
> Sampling has b
t;discoveres" a new constraint which ranks higher).
Regular faceting does more overrequest by default, and does refinement by
default. So adding refine:true and a deeper overrequest for json facets
should perform equivalently.
-Yonik
Kenny
>
> On 20-10-17 17:12, Yonik Seeley wrote:
&g
Thanks for the clear explanation. A couple of follow up questions
- can we tune overrequesting in json API?
- we do see conflicting counts but that's when we have offsets different
from 0. We have now already tested it in solr 6.6 with json api. We
sometimes get the same value in different off
Facet refinement in Solr guarantees that counts for returned
constraints are correct, but does not guarantee that the top N
returned isn't missing a constraint.
Consider the following shard counts (3 shards) for the following
constraints (aka facet values):
constraintA: 2 0 0
constraintB: 0 2 0
co
1 - 100 of 1163 matches
Mail list logo
