lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikhail Khludnev <mkhlud...@griddynamics.com>
Subject Re: Anti-Pattern in lucent-join jar?
Date Mon, 08 Dec 2014 15:19:32 GMT
On Mon, Dec 8, 2014 at 5:38 PM, Michael Sokolov <
msokolov@safaribooksonline.com> wrote:

> I get the impression there was a concern that the caller could hold on to
> the query generated by JoinUtil for too long - eg across requests in Solr.

Michael, if you still bother, SOLR-6234
<https://issues.apache.org/jira/browse/SOLR-6234> is free from this issue.
Cache keys (Queries), are fairly small and GC friendly.


> I'm not sure why the OP thinks that would happen, though.
>
Could you please expand "OP"? I didn't get it.

>
> -Mike
>
>
> On 12/08/2014 04:57 AM, Mikhail Khludnev wrote:
>
>> On Fri, Dec 5, 2014 at 10:44 PM, Darin Amos <darincs@gmail.com> wrote:
>>
>>                           public Scorer scorer(){
>>>                                  TermsWithScoreCollector collector = new
>>> TermsWithScoreCollector();
>>>                                  JoinQuery.this.s.search(
>>> JoinQuery.this.q,
>>> collector);
>>>
>>>                                  //do the rest..
>>>
>>>                          }
>>>
>>>  Darin,
>> I hardly follow, but this approach either is not efficient or even doesn't
>> work. Generally join is O(n^2) operation, which is most impls try to
>> reduce. weight.scorer() is invoked per segment, and scorer yields results
>> only from a particular segment. However, fromQuery should run across all
>> segments. Hence, TermsWithScoreCollector will collect IDs globally again
>> and again.
>> As you can see, the current JoinUtil design is much more efficient, it
>> reuses global IDs hash across all "to" segments searches.
>>
>>
>>
>


-- 
Sincerely yours
Mikhail Khludnev
Principal Engineer,
Grid Dynamics

<http://www.griddynamics.com>
<mkhludnev@griddynamics.com>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message