"start": 0,
"docs": [{
"myID": 123456,
"valueIwant": "Hello World"
},
{
"myID": 123456,
"valueIwant": "Hello Planet"
}
{
"myID": 123456,
"valueIwant": "Hello World123456"
}]]
}
}
]
}
}
Is there a way to do this? I was looking at functions but couldnt find anything
I needed.
Copy of this question can be found
https://stackoverflow.com/questions/62679939/solr-grouping-and-unique-values
Thanks
Nate
Hi All,
I have below requirement for my business:
select?fl=*&fq=MODIFY_TS:[2020-06-23T18:30:00Z TO *]&fq=PHY_KEY2: "HQ010699" OR
PHY_KEY2: "HQ010377" OR PHY_KEY2: "HQ010396" OR PHY_KEY2: "HQ010399" OR
PHY_KEY2: "HQ010404" OR PHY_KEY2: "HQ010419" OR PHY_KEY2: "HQ010426" OR
PHY_KEY2: "HQ010452"
My company is very interested in using Learning To Rank in our product search.
The problem we face is that our product search groups its results and that does
not work with LTR.
https://issues.apache.org/jira/browse/SOLR-8776
Is there any traction to getting the SOLR-8776 patch into the main bra
--
> > From: Saurabh Sharma [mailto:saurabh.infoe...@gmail.com]
> > Sent: Friday, February 14, 2020 4:36 PM
> > To: solr-user@lucene.apache.org
> > Subject: Re: Solr grouping with offset
> >
> > Hi,
> >
> > If you want to sort on your field and want
gt; > > > That way seems to me too complicated for the task.
> -Original Message-
> From: Saurabh Sharma [mailto:saurabh.infoe...@gmail.com]
> Sent: Friday, February 14, 2020 4:36 PM
> To: solr-user@lucene.apache.org
> Subject: Re: Solr grouping with offset
>
&g
t; }},
> {
> "groupValue":"163943:20200708:22:251",
> "doclist":{"numFound":1,"start":2,"docs":[]
> }},
> {
> "groupValue":"164355:20200708
"doclist":{"numFound":1,"start":2,"docs":[]
}},
{
"groupValue":"164355:20200708:22:251",
"doclist":{"numFound":1,"start":2,"docs":[]
> -Original
It would be better if you give us an example.
On Fri, 14 Feb 2020 at 17:20, Vadim Ivanov
wrote:
> Hello guys!
> I need an advise. My task is to delete some documents in collection.
> Del algorithm is following:
> Group docs by field1 with sort by field2 and delete every 3 and following
> occurr
Hello guys!
I need an advise. My task is to delete some documents in collection.
Del algorithm is following:
Group docs by field1 with sort by field2 and delete every 3 and following
occurrences in every group.
Unfortunately I didn't find easy way to do so.
Closest approach was to use group.offse
lr/guide/8_3/result-grouping.html#grouping-parameters>
for the later. Describe your expected result set if I'm not answering
your question.
On Thu, 14 Nov 2019 at 19:35, neotorand wrote:
> Hi List
> I need your help to resolve a problem for which i had been struggling for
> days.
>
ellow,item sold:1}
with second group as size and price as "8 and 8000" i have 2 documents as
below
{id:2,color:blue,item sold:3}
{id:3,price:yellow,item sold:5}
Now i want to sort the records based on item sold.
How I should look at the problem.should i remove grouping and sort
Hi,
I am trying to use JSON faceting in SOLR 7.3 along with grouping documents and
noticed that group.facet=true is not working with json.facet but it works with
flat faceting.
Query Format I used:
http://localhost:8983/solr/Collection/select?q=*:*&facet=true&facet.mincount=2&am
Cool! Paraphrasing 'Solr in Action' book: edismax is the query parser to
use when dealing with users' queries. It has a lot of customization options
and is more resilient to ill-formed queries than lucene-parser. Whenever
possible, take some time to dig deeper into those. :)
Regards,
Edward
On Fr
Thanks much! I dropped price from the fq term, changed to an edismax
parser, and boosted with
bq=price:[150+TO+*]^100
On Thu, May 9, 2019 at 7:21 AM Edward Ribeiro
wrote:
> Em qua, 8 de mai de 2019 18:56, Doug Reeder
> escreveu:
>
> >
> > Similarly, we have a filter query that only returns p
Em qua, 8 de mai de 2019 18:56, Doug Reeder
escreveu:
>
> Similarly, we have a filter query that only returns products over $150:
> fq=price:[150+TO+*]
>
> Can this be changed to a q or qf parameter where products less than $150
> have score less than any product priced $150 or more? (A price hig
ome categories
> don't have a lot of products, and grouping takes us (say) from five results
> to three.
>
> Can I "soften" the grouping, so other products by the same vendor will
> appear in the results, but with much lower score?
>
>
> Similarly, we have
We have a query to return products related to a given product. To give some
variety to the results, we group by vendor:
group=true&group.main=true&group.field=merchantId
We need at least four results to display. Unfortunately, some categories
don't have a lot of products, and grou
t
HASHTAG automatically rises to the top simply because one SITE has 1000
pages with the same HASHTAG.
That is exactly what faceting is designed to do. It is behaving exactly
as designed.
Is there a way to get a better more even distribution of top HASHTAGS for a
given date, ie facet. ..by a
because one SITE has 1000
pages with the same HASHTAG.
Is there a way to get a better more even distribution of top HASHTAGS for a
given date, ie facet. ..by a grouping or distinct or filter of some sort?
Im more interesting in knowing if a HASHTAG is used frequently among SITEs,
not just one one
t;SOTRTED_SET" docvalue type:
> https://github.com/apache/lucene-solr/blob/2480b74887eff01f729d62a57b415d772f947c91/lucene/grouping/src/java/org/apache/lucene/search/grouping/TermGroupFacetCollector.java#L313
>
> When I change schema for all int field to TrieIntField, the group facet then
> work. Since
quot; (multi value), while the TermGroupFacetCollector class
requires the facet field must have a "SORTED" or "SOTRTED_SET" docvalue type:
https://github.com/apache/lucene-solr/blob/2480b74887eff01f729d62a57b415d772f947c91/lucene/grouping/src/java/org/apache/lucene/search/grouping/TermG
I have document in solr as mentioned below
{
"event_name":"product viewed",
"event_property":["category","product_name","product_code","price","brand","color","discount","is_new_visitor"],
"event_value":["category-sunglasses","product_name-david blake grey
sunglasses","product_cod
Document structure of solr document is as mentioned below now i need to get
the document having event_name="product view" and group it by email so that
email is not duplicate.Now on listing the email how may paginate the unique
email.As the query return total number of document not the count of gro
Looks like: https://issues.apache.org/jira/browse/SOLR-11086
On Tue, Nov 6, 2018 at 8:19 AM Tomáš Hampl wrote:
>
> Hi,
>
> i have error while running grouping query by date in collection with 5
> shards. When i try same query on collection with only one shard everything
>
Hi,
i have error while running grouping query by date in collection with 5
shards. When i try same query on collection with only one shard everything
works.
*query:*
/solr/search_cz/select?q=*:*&group=true&group.field=odjezd
*part of schema.xml*
...
*collection create *
/so
I mean, you might probably count the same counts by json facet *instead*
slow grouping count, like
https://issues.apache.org/jira/browse/SOLR-7036?focusedCommentId=15601789&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15601789
On Sun, Aug 12, 2018 at 7:0
Hi Mikhail
Even after using json facets latency seems to be high if group.ngroups=true.
Regards,
Sayan
> On 12 Aug 2018, at 02:07, Mikhail Khludnev wrote:
>
> As far as I remember, groups facets can be calculated with json.facets a
> way faster.
>
>> On Sat, Aug 11, 2018 at 1:43 PM SayantiGma
As far as I remember, groups facets can be calculated with json.facets a
way faster.
On Sat, Aug 11, 2018 at 1:43 PM SayantiGmail wrote:
> Hi,
>
> The time taken to group results when the resultset has ~ 200k items is
> very high.
>
> Is there a way to optimize the performance.
> The group count
Hi,
The time taken to group results when the resultset has ~ 200k items is very
high.
Is there a way to optimize the performance.
The group count and facet count is required.
Regards,
Sayan
Hi,
Have you already tried "group.cache.percent" parameter? It might improve
grouping performance.
Or if you try CollapsingQParser, you can use expand component to acquire
all values in groups, I think.
(
https://lucene.apache.org/solr/guide/6_6/collapse-and-expand-results.html#co
Hi Yasufumi
Thanks for the reply. Yes, you are correct. I also checked the code and it
seems the same.
We are facing performance issues due to grouping so wanted to be sure that
we are not leaving out any possibility of caching the same in Query Result
Cache.
was just exploring field
ava#L120
)
But in caching grouping result, query result cache should have {query and
conditions} -> {grouped value, condition, etc...} -> {DocList} structure
cache, I think.
Thanks,
Yasufumi
2018年5月18日(金) 23:41 rubi.hali :
> Hi All
>
> Can somebody please explain if we can c
Hi All
Can somebody please explain if we can cache solr grouping results in query
result cache as i dont see any inserts in query result cache once we enabled
grouping?
--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Also, would like to understand what are the ways to optimize for performance
at search time with LTR. Queries with terms (that fetch more results) lead
to very high latency with re-rank query even for reRankDocs=24.
Is there best practices to reduce the latency?
Can fv cache help?
Shou
Thanks ilayaraja,
I updated the PR today integrating your and Alan's comments. Now it works
also in distributed mode. Please let me know what do you think :)
Cheers
Diego
On Wed, May 2, 2018, 17:46 ilayaraja wrote:
> Figured out that offset is used as part of the grouping patch
Figured out that offset is used as part of the grouping patch which I applied
(SOLR-8776) :
solr/core/src/java/org/apache/solr/handler/component/QueryComponent.java
+ if (query instanceof AbstractReRankQuery){
+topNGroups = cmd.getOffset() +
((AbstractReRankQuery)query).getReRankDocs
*
"Top K shouldn't start from the "start" parameter, if it does, it is a bug.
"***
1. I clearly see that LTR do re-rank based on the start parameter.
2. When reRankDocs=24, pageSize=24, I still get the second page of results
re-ranked by ltr plugin when I query with start=24.
Alessandro Benedett
Are you using SolrCloud or any distributed search ?
If you are using just a single Solr instance, LTR should have no problem
with pagination.
The re-rank involves the top K and then you paginate.
So if a document from the original score page 1 ends up in page 3, you will
see it at page three.
have
Between, I have applied the patch on top of solr 7.2.1 and it worked well for
me though the Test Cases were failing, yet to see why.
On another note, LTR with reRankDocs>page_size seems to create issue. For
example, Say my page_size=24 and reRankDocs=48.
For first query with start=0, it returns
Between, I have applied the patch on top of solr 7.2.1 and it worked well for
me though the Test Cases were failing, yet to see why.
On another note, LTR with reRankDocs>page_size seems to create issue. For
example, Say my page_size=24 and reRankDocs=48.
For first query with start=0, it returns
de, but unit tests in non distribute mode works.
>
> Hope this helps,
> Diego
>
> From: solr-user@lucene.apache.org At: 04/15/18 03:37:54To:
> solr-user@lucene.apache.org
> Subject: Re: Learning to Rank (LTR) with grouping
>
> People sometimes fill in the Fix/Version field
grouping
People sometimes fill in the Fix/Version field when they're creating
the JIRA, since anyone can open a JIRA it's hard to control. I took
that out just now.
Basically if the "Resolution" field doesn't indicate it's fixed, you
should assume that it hasn't been
xample.
>From the little of my opinion I believe it is quite useful.
The last activity is from 22/May/17 15:23 and no committer commented after
that.
I would assume that committers with interest or expertise on Learning To
Rank or Grouping initially didn't have free time to evaluate the pa
On 4/17/2018 5:35 AM, Alessandro Benedetti wrote:
Apache Lucene/Solr is a big project, is there anywhere in the official
Apache Lucene/Solr website where each committer list the modules of
interest/expertise ?
No, there is no repository like that. Each committer knows what their
own expertise
Hi Erick,
I have a curiosity/suggestion regarding how to speed up pending( or
forgotten ) Jiras,
is there a way to find out the most suitable committer(s) for the task and
tag them ?
Apache Lucene/Solr is a big project, is there anywhere in the official
Apache Lucene/Solr website where each commit
People sometimes fill in the Fix/Version field when they're creating
the JIRA, since anyone can open a JIRA it's hard to control. I took
that out just now.
Basically if the "Resolution" field doesn't indicate it's fixed, you
should assume that it hasn't been addressed.
Patches welcome.
Best,
Eri
:
solr-user@lucene.apache.org
Subject: Support LTR RankQuery with Grouping
I am facing issue with LTR query not supported with grouping.
I see the patch for this has been raised here
https://issues.apache.org/jira/browse/SOLR-8776
Is it available in solr/master (7.2.2) now?
Looks like this
I am facing issue with LTR query not supported with grouping.
I see the patch for this has been raised here
https://issues.apache.org/jira/browse/SOLR-8776
Is it available in solr/master (7.2.2) now?
Looks like this patch is not merged yet.
-
--Ilay
--
Sent from: http://lucene.472066
Thanks Roopa.
I was expecting that the issue has been fixed in solr 7.0 as per here
https://issues.apache.org/jira/browse/SOLR-8776.
Let me see why it is still not working on solr-ltr-7.2.1
-
--Ilay
--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Hi Ilay,
I am still on Solr 6.6.0 and did not patch the grouping fix.
I implemented a temporary workaround solution to have 2 async request from
the web application 1st with grouping 2nd without grouping and merged the
results.
This solution worked for my case as we were getting grouping results
Hi Roopa & Deigo,
I am facing same issue with grouping. Currently, am on Solr 7.2.1 but still
see that grouping with LTR is not working. Did you apply it as patch or the
latest solr version has the fix already?
Ilay
-
--Ilay
--
Sent from: http://lucene.472066.n3.nabble.com/Solr-
Message-
> From: Emir Arnautović [mailto:emir.arnauto...@sematext.com]
> Sent: Thursday, January 25, 2018 4:31 PM
> To: solr-user@lucene.apache.org
> Subject: Re: Grouping on Exact Match
>
> Hi Gopesh,
> No it is not - at least not in a way I was thinking. I should have b
I am using the above query.
Thanks,
Gopesh Sharma
-Original Message-
From: Emir Arnautović [mailto:emir.arnauto...@sematext.com]
Sent: Thursday, January 25, 2018 4:31 PM
To: solr-user@lucene.apache.org
Subject: Re: Grouping on Exact Match
Hi Gopesh,
No it is not - at least not in a
Hi Gopesh,
No it is not - at least not in a way I was thinking. I should have been more
precise - I meant tokenized. So you are grouping on the field that uses this
field type? Can you share query?
Thanks,
Emir
--
Monitoring - Log Management - Alerting - Anomaly Detection
Solr & Elasticse
...@sematext.com]
Sent: Thursday, January 25, 2018 4:16 PM
To: solr-user@lucene.apache.org
Subject: Re: Grouping on Exact Match
Hi Gopesh,
You are probably grouping on field that is analysed so “Consulting” is group
term. What you need to do is to have name field that is not alalysed and group
on
Hi Gopesh,
You are probably grouping on field that is analysed so “Consulting” is group
term. What you need to do is to have name field that is not alalysed and group
on that field. If you want to “group” on query input, that is not grouping -
you simply use phrase query and all results are of
Hello All,
I am grouping the results but the groups are not happening on the exact match.
For Example : I have 5 documents with name Construction Company, Construction
Tower, Tower Company, Tower House and again Construction Company. If I search
for Construction Company with grouping I am
wrote:
> Roopa, did you try collapsing instead of grouping? it would work with ltr..
>
> From: solr-user@lucene.apache.org At: 01/11/18 16:48:26To:
> solr-user@lucene.apache.org
> Subject: Re: Learning to Rank (LTR) with grouping
>
> Solution that I implemented currently is:
> S
Roopa, did you try collapsing instead of grouping? it would work with ltr..
From: solr-user@lucene.apache.org At: 01/11/18 16:48:26To:
solr-user@lucene.apache.org
Subject: Re: Learning to Rank (LTR) with grouping
Solution that I implemented currently is:
Since we have a web application which
with no grouping + LTR
Merge 1) & 2) in web app.
Doing a performance test now. Since there are only 10 results for these
queries and the queries are executed in parallel, I don't foresee any
problems.
Thanks!
Roopa
On Thu, Jan 4, 2018 at 10:24 AM, Roopa Rao wrote:
> Hi,
>
> An
On 1/6/2018 11:25 AM, SANJAY. wrote:
Please let me know how to achieve group by in solr could env.
We tried grouping in solr cloud shard replicas to fetch unique search result
from solr for custom field we .
we are getting exception saying unexpected docvalues type "SORTED_SET
(expected S
Hi,
Please let me know how to achieve group by in solr could env.
We tried grouping in solr cloud shard replicas to fetch unique search result
from solr for custom field we .
we are getting exception saying unexpected docvalues type "SORTED_SET
(expected SORTED)"
We are using solr
its not working with grouping in the base version, I am trying to
> evaluate if there is any alternative way to make it work in 6.6 versus
> upgrading to 7.0.
>
> Any guidance you could provide on what can be done to use 6.6 with
> grouping + LTR or any alternatives would be helpful.
rning partial result and sometimes does nothing (oblivious to
timeAllowed)
1) Can somebody explain this behavior?
2) Does timeAllowed parameter work with grouping in SOLR-6.5.1 (We saw
SOLR-6156 issue that was updated 22/Apr/15 09:20 in the last time)?
3) If query was stopped, partial results will be
rning partial result and sometimes does nothing (oblivious to
timeAllowed)
1) Can somebody explain this behavior?
2) Does timeAllowed parameter work with grouping in SOLR-6.5.1 (We saw
SOLR-6156 issue that was updated 22/Apr/15 09:20 in the last time)?
3) If query was stopped, partial results will be
Hi Diego,
Thank you for looking into it further.
We recently ported over to 6.6 version solely to use LTR feature as it is
critical for us.
Since its not working with grouping in the base version, I am trying to
evaluate if there is any alternative way to make it work in 6.6 versus
upgrading to
changes.
>>>
>>> Are you interested in reranking the groups or also in reranking the
>>> documents inside each group?
>>>
>>> Cheers,
>>> Diego
>>>
>>>
>>> From: solr-user@lucene.apache.org At: 12/09/17 19:07:25To:
>
46 PM, tomerg wrote:
> hey,
>
> i'm using solr 6.5.1 with solrCloud mode.
> i use grouping for my results.
> i want to use rank query(rq) in order to rerank the top groups(with ltr).
> it's ok for me to rerank the groups only by reranking one of the documents
> in t
groups or also in reranking the
>> documents inside each group?
>>
>> Cheers,
>> Diego
>>
>>
>> From: solr-user@lucene.apache.org At: 12/09/17 19:07:25To:
>> solr-user@lucene.apache.org
>> Subject: Re: Learning to Rank (LTR) with grouping
hey,
i'm using solr 6.5.1 with solrCloud mode.
i use grouping for my results.
i want to use rank query(rq) in order to rerank the top groups(with ltr).
it's ok for me to rerank the groups only by reranking one of the documents
in the group.
i saw in issue SOLR-8776 that rank queri
>
> From: solr-user@lucene.apache.org At: 12/09/17 19:07:25To:
> solr-user@lucene.apache.org
> Subject: Re: Learning to Rank (LTR) with grouping
>
> Hi I tried to apply this JIRA SOLR-8776 as a patch as this feature is
> critical.
>
> Here are the steps I took on my mac:
>
> On br
-user@lucene.apache.org
Subject: Re: Learning to Rank (LTR) with grouping
Hi I tried to apply this JIRA SOLR-8776 as a patch as this feature is
critical.
Here are the steps I took on my mac:
On branch branch_6_5
Your branch is up-to-date with 'origin/branch_6_5'
patch -p1 -i 162.patch --dry-run
look into this and see how I could patch this.
>
> Thank you for your quick response,
> Roopa
>
>
> On Fri, Dec 8, 2017 at 5:44 PM, Diego Ceccarelli <
> diego.ceccare...@gmail.com> wrote:
>
>> Hi Roopa,
>>
>> LTR is implemented using RankQuery, and
Hi Diego,
Thank you, I will look into this and see how I could patch this.
Thank you for your quick response,
Roopa
On Fri, Dec 8, 2017 at 5:44 PM, Diego Ceccarelli wrote:
> Hi Roopa,
>
> LTR is implemented using RankQuery, and at the moment grouping doens't
> support RankQu
Hi Roopa,
LTR is implemented using RankQuery, and at the moment grouping doens't
support RankQuery.
I opened a jira item time ago
(https://issues.apache.org/jira/browse/SOLR-8776) and I would be happy
to receive feedback on that. You can find the code here
https://github.com/apache/lucene
Hi,
I am using grouping and LTR together and the results are not getting
re-rank as it does without grouping.
I am passing &rq parameter.
Does LTR work with grouping on?
Solr version 6.5
Thank you,
Roopa
case.
Testing environment: Solr 7.0.1, 1 core with 70GB data (~1.000.000 documents),
no shards
Akos
-Original Message-
From: Mikhail Khludnev [mailto:m...@apache.org]
Sent: Thursday, November 23, 2017 8:38 AM
To: solr-user
Subject: Re: Result grouping performance
Akos,
Can you provide
Akos,
Can you provide your request params? Do you just group and/or count grouped
facets?
Can you clarify how field collapsing is different from grouping, just make
it unambiguous?
On Wed, Nov 22, 2017 at 4:13 PM, Kempelen, Ákos <
akos.kempe...@wolterskluwer.com> wrote:
> Hello,
Have you enabled docValues (and reindexed from scratch) on the field
you're grouping on?
Best,
Erick
On Wed, Nov 22, 2017 at 5:13 AM, Kempelen, Ákos
wrote:
> Hello,
>
> I am migrating our codebase from Solr 4.7 to 7.0.1 but the performance of
> result grouping seems very poo
Hello,
I am migrating our codebase from Solr 4.7 to 7.0.1 but the performance of
result grouping seems very poor using the newer Solr.
For example a simple MatchAllDocsQuery takes 5 sec on Solr4.7, and 21 sec on
Solr7.
I wonder what causes the x4 difference in time? We hoped that newer Solr
While I can't say whether it affects you in this case, Solr 6.4.1 has
serious performance issues. I'd suggest upgrading to at least 6.4.2.
--Ere
31.5.2017, 14.16, Marek Tichy kirjoitti:
Hi,
I'm getting a very slow response times on grouping, especially on facet
grouping.
W
Use group.cache.percent – for your index size, it might work well.
Thanks,
On 5/31/17, 4:16 AM, "Marek Tichy" wrote:
Hi,
I'm getting a very slow response times on grouping, especially on facet
grouping.
Without grouping, the query takes 14ms
Did you try sub-facets ( http://yonik.com/json-facet-api/ ) if that meets
your facet grouping requirements or try Collapse/Expand Results.
https://cwiki.apache.org/confluence/display/solr/Collapse+and+Expand+Results
Thnx
On Wed, May 31, 2017 at 7:16 AM, Marek Tichy wrote:
> Hi,
>
Hi,
I'm getting a very slow response times on grouping, especially on facet
grouping.
Without grouping, the query takes 14ms, faceting 57ms.
With grouping, the query time goes up to 1131ms, with facet grouping,
the faceting goes up to the unbearable 12103 ms.
Single solr instance, 92708
Hi Tien
Consider using the export handler if you can. Then you have no paging.
When you are having a paging problem you might want to think of the use case --
how many of your users will be willing to page deeply? If they give up, then
you have lost already.
Cheers -- Rick
On May 29, 2017 7:58
Hello,
I group search result by a field (with high cardinality)
I paginate search page using num of groups using param group.ngroups=true.
But that cause high CPU issue. So i turn off it.
Without ngroups=true, i can't get the num of groups so pagination is not
correct because i must use numFound,
Shacky
Quote "A multivalued field is useful when there are more than one value present
for the field. An easy example would be tags, there can be multiple tags that
need to be indexed...". So yes, you are on the right track. Cheers -- Rick
https://stackoverflow.com/questions/5800762/what-is-the-u
Hi,
I need to create a new collection on my Solr 6.1.0 cluster where every row
is a "content" and every content can belong to one or many categories,
which are specified in a multivalued field "categories".
In my web app the user can search by categories, and if wanted it can even
group results by
Without using ngroups=true, is there any way to handle pagination correctly
when we collapse result using grouping?
Regards,
Tien
On Tue, May 23, 2017 at 9:55 PM, Nguyen Manh Tien wrote:
> The collapse field is high-cardinality field. I haven't profiling yet but
> will do it.
needs to be done.
>
> Have you tried profiling to see where the CPU time is being spent?
>
> Best,
> Erick
>
> On Tue, May 23, 2017 at 7:46 AM, Nguyen Manh Tien
> wrote:
> > Hi All,
> >
> > I recently switch from solr field collapse/expand to grouping for
> c
gt; I recently switch from solr field collapse/expand to grouping for collapse
> search result
> All seem good but CPU is always high (80-100%) when i set param
> group.ngroups=true.
>
> We set ngroups=true to get number of groups so that we can paginate search
> result correctly.
&g
Hi All,
I recently switch from solr field collapse/expand to grouping for collapse
search result
All seem good but CPU is always high (80-100%) when i set param
group.ngroups=true.
We set ngroups=true to get number of groups so that we can paginate search
result correctly.
Due to CPU issue we
Hi All,
At the moment RankQueries [1] are not supported when you perform grouping:
if you perform a ReRankQuery and ask for the groups, reranking will be ignored
in the scoring.
In SOLR-8776, I added support for ReRankQueries in grouping and I opened a PR
on github [2].
ReRankQueries are
for both q and fq
--
View this message in context:
http://lucene.472066.n3.nabble.com/Search-inside-grouping-list-tp4333488p4334206.html
Sent from the Solr - User mailing list archive at Nabble.com.
--
Monitoring * Alerting * Anomaly Detection * Centralized Log Management
Solr & Elasticse
Yes. I am getting the same result for both q and fq
--
View this message in context:
http://lucene.472066.n3.nabble.com/Search-inside-grouping-list-tp4333488p4334206.html
Sent from the Solr - User mailing list archive at Nabble.com.
Do you get the same result if you use q instead of fq?
On 09.05.2017 07:38, donjose wrote:
Hi Emir,
Grouping by default is part of the configuration
true
assetid
true
Don.
--
View this message in context:
http://lucene.472066.n3.nabble.com
Hi Emir,
Grouping by default is part of the configuration
true
assetid
true
Don.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Search-inside-grouping-list-tp4333488p4334136.html
Sent from the Solr - User mailing list
Hi Don,
This is query without grouping and returns expected results. But when
you apply grouping by some field, you get wrong results? Can you share
query results and query with grouping.
Emir
On 08.05.2017 14:28, donjose wrote:
Hi Emir,
Thank you for the response.
Please find the query
Hi Emir,
Thank you for the response.
Please find the query which i am sending to SOLR
http://localhost:8983/solr/pema/select?fq=color:red&indent=on&q=*:*&wt=json
Regards,
Don.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Search-inside-grouping-list-tp433
Hi,
Can you please provide full query that you are sending to Solr.
Thanks,
Emir
On 08.05.2017 07:18, donjose wrote:
Could anyone can please reply for this query
--
View this message in context:
http://lucene.472066.n3.nabble.com/Search-inside-grouping-list-tp4333488p4333870.html
Sent
1 - 100 of 794 matches
Mail list logo
