Solr JOIN Performance 4.10.0 vs 7.x

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

Re: Solr multicore join performance tuning

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

Solr multicore join performance tuning

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

Re: ACL implementation: Pseudo-join performance Atomic Updates

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

Re: ACL implementation: Pseudo-join performance Atomic Updates

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

Re: ACL implementation: Pseudo-join performance Atomic Updates

, 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

Re: ACL implementation: Pseudo-join performance Atomic Updates

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

Re: ACL implementation: Pseudo-join performance Atomic Updates

...@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

Re: ACL implementation: Pseudo-join performance Atomic Updates

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

Re: ACL implementation: Pseudo-join performance Atomic Updates

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

ACL implementation: Pseudo-join performance Atomic Updates

-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

Re: ACL implementation: Pseudo-join performance Atomic Updates

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

Re: ACL implementation: Pseudo-join performance Atomic Updates

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

Re: ACL implementation: Pseudo-join performance Atomic Updates

/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

Re: ACL implementation: Pseudo-join performance Atomic Updates

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

RE: Solr 4.0 - Join performance

@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

Re: Solr 4.0 - Join performance

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

Re: Solr 4.0 - Join performance

/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

RE: Solr 4.0 - Join performance

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

Re: Solr 4.0 - Join performance

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

RE: Solr 4.0 - Join performance

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

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

RE: Solr 4.0 - Join performance

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.

RE: Solr 4.0 - Join performance

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

Re: Solr 4.0 - Join performance

...@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

Re: Solr 4.0 - Join performance

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,

RE: Solr 4.0 - Join performance

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

Re: Solr 4.0 - Join performance

@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

RE: Solr 4.0 - Join performance

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

Solr 4.0 - Join performance

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 -

Re: Solr 4.0 - Join performance

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

Re: Solr 4.0 - Join performance

. 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

Join performance?

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

Re: Join performance?

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