Hello,
I'm wondering what performance improvements occurred in Solr JOIN from
4.10.0 to 7.x. I noticed that the performance is quicker, but from looking
at the code in JoinQParserPlugin it isn't much change.
I saw that in Solr 5.x passing score=none would invoke Lucene's join
algorithm, which
What a solr version, query parameters and debug output?
26.01.2016 6:38 пользователь "Bhawna Asnani"
написал:
> Hi,
> I am using solr multicore join queries for some admin filters. The queries
> are really slow taking up to 40-60 seconds ins some cases.
>
> I recently
Hi,
I am using solr multicore join queries for some admin filters. The queries
are really slow taking up to 40-60 seconds ins some cases.
I recently read that the schema field used to join to should have
'docValues=true'.
Besides that, any suggestion to improve the performance?
-Bhawna
roman.ch...@gmail.com
wrote:
On Sun, Jul 14, 2013 at 1:45 PM, Oleg Burlaca oburl...@gmail.com
wrote:
Hello Erick,
Join performance is most sensitive to the number of values
in the field being joined on. So if you have lots and lots of
distinct values in the corpus, join
it if it did, and
this
would
be pretty cool
Erick
On Mon, Jul 15, 2013 at 6:52 PM, Roman Chyla roman.ch...@gmail.com
wrote:
On Sun, Jul 14, 2013 at 1:45 PM, Oleg Burlaca oburl...@gmail.com
wrote:
Hello Erick,
Join performance is most sensitive to the number
, Roman Chyla roman.ch...@gmail.com
wrote:
On Sun, Jul 14, 2013 at 1:45 PM, Oleg Burlaca oburl...@gmail.com
wrote:
Hello Erick,
Join performance is most sensitive to the number of values
in the field being joined on. So if you have lots and lots
Roman:
Did this ever make into a JIRA? Somehow I missed it if it did, and this would
be pretty cool
Erick
On Mon, Jul 15, 2013 at 6:52 PM, Roman Chyla roman.ch...@gmail.com wrote:
On Sun, Jul 14, 2013 at 1:45 PM, Oleg Burlaca oburl...@gmail.com wrote:
Hello Erick,
Join performance
...@gmail.com
wrote:
On Sun, Jul 14, 2013 at 1:45 PM, Oleg Burlaca oburl...@gmail.com
wrote:
Hello Erick,
Join performance is most sensitive to the number of values
in the field being joined on. So if you have lots and lots of
distinct values in the corpus, join performance
cool
Erick
On Mon, Jul 15, 2013 at 6:52 PM, Roman Chyla roman.ch...@gmail.com
wrote:
On Sun, Jul 14, 2013 at 1:45 PM, Oleg Burlaca oburl...@gmail.com
wrote:
Hello Erick,
Join performance is most sensitive to the number of values
in the field being joined on. So
On Sun, Jul 14, 2013 at 1:45 PM, Oleg Burlaca oburl...@gmail.com wrote:
Hello Erick,
Join performance is most sensitive to the number of values
in the field being joined on. So if you have lots and lots of
distinct values in the corpus, join performance will be affected.
Yep, we have
-join
performance for large datasets (i.e. initial filtered set of IDs).
Regards,
Oleg
P.S. we found that having the list of all users that have access for each
record is better overall, because there are much more read requests (people
accessing the library) then write requests (a new user
is that clearly updating all documents in the index is a
non-starter.
-- Jack Krupansky
-Original Message-
From: Oleg Burlaca
Sent: Sunday, July 14, 2013 11:02 AM
To: solr-user@lucene.apache.org
Subject: ACL implementation: Pseudo-join performance Atomic Updates
Hello all,
Situation:
We
Join performance is most sensitive to the number of values
in the field being joined on. So if you have lots and lots of
distinct values in the corpus, join performance will be affected.
bq: I suppose the delete/reindex approach will not change soon
There is ongoing work (search the JIRA
/SOLR-1913
But the bottom line is that clearly updating all documents in the index is
a non-starter.
-- Jack Krupansky
-Original Message- From: Oleg Burlaca
Sent: Sunday, July 14, 2013 11:02 AM
To: solr-user@lucene.apache.org
Subject: ACL implementation: Pseudo-join performance
Hello Erick,
Join performance is most sensitive to the number of values
in the field being joined on. So if you have lots and lots of
distinct values in the corpus, join performance will be affected.
Yep, we have a list of unique Id's that we get by first searching for
records
where
@lucene.apache.org
Subject: Re: Solr 4.0 - Join performance
The solr.GeoHashFieldType is useless; I'd like to see it deprecated then
removed. You'll need to go with unreleased code and apply patches or wait
till Solr 4.
~ David
On Aug 29, 2012, at 10:53 AM, Eric Khoury [via Lucene] wrote
To: [hidden email]x-msg://175/user/SendEmail.jtp?type=nodenode=4008368i=1
Subject: Re: Solr 4.0 - Join performance
The solr.GeoHashFieldType is useless; I'd like to see it deprecated then
removed. You'll need to go with unreleased code and apply patches or wait
till Solr 4.
~ David
On Aug 29
/SendEmail.jtp?type=nodenode=4003852i=1
Subject: RE: Solr 4.0 - Join performance
You would index rectangles of 0 height but that have a left edge 'x' of the
start time and a right edge 'x' of your end time. You can index a variable
number of these per Solr document and then query by either a point
To: solr-user@lucene.apache.org
Subject: Re: Solr 4.0 - Join performance
Solr 4 is certainly the goal. There's a bit of a setback at the moment until
some of the Lucene spatial API is re-thought. I'm working heavily on such
things this week.
~ David
On Aug 28, 2012, at 6:22 PM, Eric
email]x-msg://228/user/SendEmail.jtp?type=nodenode=4004060i=1
Subject: Re: Solr 4.0 - Join performance
Solr 4 is certainly the goal. There's a bit of a setback at the moment until
some of the Lucene spatial API is re-thought. I'm working heavily on such
things this week.
~ David
On Aug
Thanks David, will work around this issue for now, and will keep an eye out for
changes to solr-3304.Good luck with the rethink.Eric.
Date: Wed, 29 Aug 2012 08:44:14 -0700
From: dsmi...@mitre.org
To: solr-user@lucene.apache.org
Subject: Re: Solr 4.0 - Join performance
: Solr 4.0 - Join performance
You would index rectangles of 0 height but that have a left edge 'x' of the
start time and a right edge 'x' of your end time. You can index a variable
number of these per Solr document and then query by either a point or
another rectangle to find documents which
this message in context:
http://lucene.472066.n3.nabble.com/Solr-4-0-Join-performance-tp3998827p4001404.html
Sent from the Solr - User mailing list archive at Nabble.com.
Hi Mikhail, was trying to figure out if solr-3076 made it into the beta, but
since the issue is still marked as opened, I take it it didn't yet?Thanks,Eric.
From: mkhlud...@griddynamics.com
Date: Fri, 3 Aug 2012 00:06:36 +0400
Subject: Re: Solr 4.0 - Join performance
To: ekhour
...@griddynamics.com
Date: Fri, 3 Aug 2012 00:06:36 +0400
Subject: Re: Solr 4.0 - Join performance
To: ekhour...@hotmail.com; solr-user@lucene.apache.org
Eric,
you can take last patch from SOLR-3076
[image: Text File]
https://issues.apache.org/jira/secure/attachment/12536717/SOLR
Stepping back a bit, the reason you are using multiple cores with a join is
because Solr doesn't have a multi-valued numeric range type. The spatial work
I'm doing in Lucene-spatial does, and it's 2-dimensional for an x y whereas
your case calls for one dimension. It's taking a bit of time,
Thanks David, that does indeed sound like it'll help. Is there an issue number
I can use to track development\availability?Eric.
From: dsmi...@mitre.org
To: solr-user@lucene.apache.org
Subject: Re: Solr 4.0 - Join performance
Date: Tue, 14 Aug 2012 20:15:27 +
Stepping back a bit
@lucene.apache.org
Subject: Re: Solr 4.0 - Join performance
Date: Tue, 14 Aug 2012 20:15:27 +
Stepping back a bit, the reason you are using multiple cores with a join is
because Solr doesn't have a multi-valued numeric range type. The spatial
work I'm doing in Lucene-spatial does
To: solr-user@lucene.apache.org
Subject: Re: Solr 4.0 - Join performance
Date: Tue, 14 Aug 2012 20:50:43 +
This one should work for now:
https://issues.apache.org/jira/browse/SOLR-3304
If you're comfortable with checking out Lucene/Solr and applying a patch,
then you can do it yourself
Hello all,
I’m testing out the new join feature, hitting some perf
issues, as described in Erick’s article
(http://architects.dzone.com/articles/solr-experimenting-join).
Basically, I’m using 2 objects in solr (this is a simplified
view):
Item
- Id
- Name
Grant
- ItemId
-
Hello,
You can check my record.
https://issues.apache.org/jira/browse/SOLR-3076?focusedCommentId=13415644page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13415644
I'm still working on precise performance measurement.
On Thu, Aug 2, 2012 at 6:45 PM, Eric Khoury
.
I don't currently have build the dev tree, you wouldn't have a patch for
the alpha build handy?
If not, when do you think this'll be available in a nightly build?
Thanks again,
Eric.
From: mkhlud...@griddynamics.com
Date: Thu, 2 Aug 2012 22:38:13 +0400
Subject: Re: Solr 4.0 - Join
I am trying to optimize performance of solr with our collection. The collection
has 208M records with index size of about 80GB. The machine has 16GB and I am
allocating about 14GB to solr.
I am using self join statement in filter query like this:
q=(general search term)
fq={!join
On Mon, Jul 18, 2011 at 12:48 PM, Kanduru, Ajay (NIH/NLM/LHC) [C]
akand...@mail.nih.gov wrote:
I am trying to optimize performance of solr with our collection. The
collection has 208M records with index size of about 80GB. The machine has
16GB and I am allocating about 14GB to solr.
I am
34 matches
Mail list logo