On Mon, Dec 8, 2014 at 5:38 PM, Michael Sokolov < msoko...@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 <dari...@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> <mkhlud...@griddynamics.com>
