Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.1, 6.0
    • Component/s: None
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      Like we just did on exact phrases and conjunctions, we should also support approximations on disjunctions in order to apply "matches()" lazily.

      1. LUCENE-6244.patch
        31 kB
        Adrien Grand
      2. LUCENE-6244.patch
        29 kB
        Adrien Grand
      3. LUCENE-6244.patch
        28 kB
        Adrien Grand
      4. wikibig.tasks
        0.9 kB
        Adrien Grand

        Activity

        Hide
        Adrien Grand added a comment -

        Here is a patch. In order to keep things simple I made DisjunctionScorer handle all clauses as if they supported approximations. When they don't, I just use the scorer itself as an approximation and matches() always returns true.

        When you do not need scores, we will stop calling matches() after we have found a single matching clause.

        luceneutil looks happy:

                            TaskQPS baseline      StdDev   QPS patch      StdDev                Pct diff
                          Fuzzy2       57.41      (6.2%)       55.70      (9.3%)   -3.0% ( -17% -   13%)
                      AndHighMed      204.81      (2.2%)      203.24      (2.0%)   -0.8% (  -4% -    3%)
                         Respell       72.45      (3.1%)       72.04      (3.7%)   -0.6% (  -7% -    6%)
                    OrNotHighMed      190.72      (1.5%)      189.87      (1.3%)   -0.4% (  -3% -    2%)
                    HighSpanNear       44.31      (3.7%)       44.12      (3.2%)   -0.4% (  -7% -    6%)
                    OrHighNotMed       98.12      (2.1%)       97.74      (2.3%)   -0.4% (  -4% -    4%)
                     LowSpanNear       24.78      (5.5%)       24.71      (5.6%)   -0.3% ( -10% -   11%)
                       MedPhrase      135.21      (2.1%)      134.82      (1.9%)   -0.3% (  -4% -    3%)
                      HighPhrase        4.29      (4.3%)        4.28      (4.5%)   -0.3% (  -8% -    8%)
                 LowSloppyPhrase       96.57      (3.0%)       96.35      (3.1%)   -0.2% (  -6% -    6%)
                       OrHighMed       79.74      (6.3%)       79.56      (5.8%)   -0.2% ( -11% -   12%)
                 MedSloppyPhrase       52.22      (2.7%)       52.10      (2.5%)   -0.2% (  -5% -    5%)
                   OrNotHighHigh       36.47      (0.9%)       36.38      (0.6%)   -0.2% (  -1% -    1%)
                    OrNotHighLow      784.22      (2.9%)      782.46      (3.5%)   -0.2% (  -6% -    6%)
                HighSloppyPhrase       27.94      (3.1%)       27.89      (3.1%)   -0.2% (  -6% -    6%)
                   OrHighNotHigh       35.84      (1.4%)       35.78      (1.2%)   -0.2% (  -2% -    2%)
                         Prefix3       74.10      (3.0%)       73.99      (2.6%)   -0.2% (  -5% -    5%)
                         MedTerm      306.95      (1.3%)      306.54      (1.4%)   -0.1% (  -2% -    2%)
                        Wildcard       27.77      (2.1%)       27.74      (2.1%)   -0.1% (  -4% -    4%)
                      OrHighHigh       41.35      (6.3%)       41.30      (6.4%)   -0.1% ( -12% -   13%)
                       OrHighLow       12.41      (6.8%)       12.41      (6.6%)   -0.0% ( -12% -   14%)
                       LowPhrase       75.12      (1.5%)       75.14      (1.7%)    0.0% (  -3% -    3%)
                        PKLookup      266.10      (2.5%)      266.28      (2.7%)    0.1% (  -5% -    5%)
                     MedSpanNear       36.94      (3.8%)       36.99      (3.9%)    0.1% (  -7% -    8%)
                     AndHighHigh       90.05      (2.0%)       90.18      (1.8%)    0.1% (  -3% -    3%)
                        HighTerm       74.97      (1.5%)       75.09      (1.4%)    0.2% (  -2% -    3%)
                    OrHighNotLow       80.68      (2.7%)       80.87      (2.5%)    0.2% (  -4% -    5%)
                          IntNRQ        7.50      (3.1%)        7.52      (2.9%)    0.4% (  -5% -    6%)
                         LowTerm      856.75      (3.0%)      861.68      (3.1%)    0.6% (  -5% -    6%)
                      AndHighLow      823.49      (3.6%)      831.80      (3.6%)    1.0% (  -5% -    8%)
                          Fuzzy1       58.81      (8.0%)       59.79     (10.2%)    1.7% ( -15% -   21%)
        
        Show
        Adrien Grand added a comment - Here is a patch. In order to keep things simple I made DisjunctionScorer handle all clauses as if they supported approximations. When they don't, I just use the scorer itself as an approximation and matches() always returns true. When you do not need scores, we will stop calling matches() after we have found a single matching clause. luceneutil looks happy: TaskQPS baseline StdDev QPS patch StdDev Pct diff Fuzzy2 57.41 (6.2%) 55.70 (9.3%) -3.0% ( -17% - 13%) AndHighMed 204.81 (2.2%) 203.24 (2.0%) -0.8% ( -4% - 3%) Respell 72.45 (3.1%) 72.04 (3.7%) -0.6% ( -7% - 6%) OrNotHighMed 190.72 (1.5%) 189.87 (1.3%) -0.4% ( -3% - 2%) HighSpanNear 44.31 (3.7%) 44.12 (3.2%) -0.4% ( -7% - 6%) OrHighNotMed 98.12 (2.1%) 97.74 (2.3%) -0.4% ( -4% - 4%) LowSpanNear 24.78 (5.5%) 24.71 (5.6%) -0.3% ( -10% - 11%) MedPhrase 135.21 (2.1%) 134.82 (1.9%) -0.3% ( -4% - 3%) HighPhrase 4.29 (4.3%) 4.28 (4.5%) -0.3% ( -8% - 8%) LowSloppyPhrase 96.57 (3.0%) 96.35 (3.1%) -0.2% ( -6% - 6%) OrHighMed 79.74 (6.3%) 79.56 (5.8%) -0.2% ( -11% - 12%) MedSloppyPhrase 52.22 (2.7%) 52.10 (2.5%) -0.2% ( -5% - 5%) OrNotHighHigh 36.47 (0.9%) 36.38 (0.6%) -0.2% ( -1% - 1%) OrNotHighLow 784.22 (2.9%) 782.46 (3.5%) -0.2% ( -6% - 6%) HighSloppyPhrase 27.94 (3.1%) 27.89 (3.1%) -0.2% ( -6% - 6%) OrHighNotHigh 35.84 (1.4%) 35.78 (1.2%) -0.2% ( -2% - 2%) Prefix3 74.10 (3.0%) 73.99 (2.6%) -0.2% ( -5% - 5%) MedTerm 306.95 (1.3%) 306.54 (1.4%) -0.1% ( -2% - 2%) Wildcard 27.77 (2.1%) 27.74 (2.1%) -0.1% ( -4% - 4%) OrHighHigh 41.35 (6.3%) 41.30 (6.4%) -0.1% ( -12% - 13%) OrHighLow 12.41 (6.8%) 12.41 (6.6%) -0.0% ( -12% - 14%) LowPhrase 75.12 (1.5%) 75.14 (1.7%) 0.0% ( -3% - 3%) PKLookup 266.10 (2.5%) 266.28 (2.7%) 0.1% ( -5% - 5%) MedSpanNear 36.94 (3.8%) 36.99 (3.9%) 0.1% ( -7% - 8%) AndHighHigh 90.05 (2.0%) 90.18 (1.8%) 0.1% ( -3% - 3%) HighTerm 74.97 (1.5%) 75.09 (1.4%) 0.2% ( -2% - 3%) OrHighNotLow 80.68 (2.7%) 80.87 (2.5%) 0.2% ( -4% - 5%) IntNRQ 7.50 (3.1%) 7.52 (2.9%) 0.4% ( -5% - 6%) LowTerm 856.75 (3.0%) 861.68 (3.1%) 0.6% ( -5% - 6%) AndHighLow 823.49 (3.6%) 831.80 (3.6%) 1.0% ( -5% - 8%) Fuzzy1 58.81 (8.0%) 59.79 (10.2%) 1.7% ( -15% - 21%)
        Hide
        Robert Muir added a comment -

        When you ran the benchmark, did you disable BooleanScorer so that DisjunctionScorer was forced to be used?

        Show
        Robert Muir added a comment - When you ran the benchmark, did you disable BooleanScorer so that DisjunctionScorer was forced to be used?
        Hide
        Adrien Grand added a comment -

        How funny I've spent entire days working on BooleanScorer and now I forget to disable it to benchmark BS2. Indeed it was not disabled and luceneutil reports slowdowns of about 20%. Profiling doesn't show a clear culprit so I'll try to redo the patch step by step and see how I can make things better.

        Show
        Adrien Grand added a comment - How funny I've spent entire days working on BooleanScorer and now I forget to disable it to benchmark BS2. Indeed it was not disabled and luceneutil reports slowdowns of about 20%. Profiling doesn't show a clear culprit so I'll try to redo the patch step by step and see how I can make things better.
        Hide
        Robert Muir added a comment -

        I only brought it up because I think its a trap. Maybe later we should fix this, for example have BS1 vs BS2 explicitly separate in the benchmarks so we never have to worry about this. Its also a trap to put the nocommits in your code needed to do the benchmark properly... one of these days, one of us is going to make a commit disabling BS1 on accident.

        Show
        Robert Muir added a comment - I only brought it up because I think its a trap. Maybe later we should fix this, for example have BS1 vs BS2 explicitly separate in the benchmarks so we never have to worry about this. Its also a trap to put the nocommits in your code needed to do the benchmark properly... one of these days, one of us is going to make a commit disabling BS1 on accident.
        Hide
        Adrien Grand added a comment -

        I agree it would be important that our benchmarks track the performance of BS2 as this scorer is probably used pretty often!

        I worked a bit more on the patch in order to get back some performance. Because things are structured differently, I lost the feature that we confirm at most one clause per doc, but at least performance on simple queries is back (with BS1 disabled this time):

                            TaskQPS baseline      StdDev   QPS patch      StdDev                Pct diff
                         Respell       70.77      (3.2%)       69.96      (5.6%)   -1.1% (  -9% -    7%)
                          Fuzzy2       57.49      (7.8%)       57.03     (10.1%)   -0.8% ( -17% -   18%)
                     AndHighHigh       90.13      (1.7%)       89.61      (2.1%)   -0.6% (  -4% -    3%)
                          IntNRQ        7.32      (5.2%)        7.28      (5.3%)   -0.5% ( -10% -   10%)
                    OrNotHighLow      824.56      (3.5%)      821.47      (4.0%)   -0.4% (  -7% -    7%)
                        HighTerm       73.82      (1.3%)       73.57      (1.1%)   -0.3% (  -2% -    2%)
                       LowPhrase       74.18      (1.9%)       73.96      (1.9%)   -0.3% (  -4% -    3%)
                    HighSpanNear       43.58      (3.4%)       43.49      (3.7%)   -0.2% (  -7% -    7%)
                         Prefix3       72.06      (3.9%)       71.91      (3.8%)   -0.2% (  -7% -    7%)
                        PKLookup      265.53      (3.1%)      265.02      (2.8%)   -0.2% (  -5% -    5%)
                      HighPhrase        4.24      (4.2%)        4.23      (4.4%)   -0.1% (  -8% -    8%)
                   OrHighNotHigh       35.52      (1.5%)       35.51      (1.6%)   -0.0% (  -3% -    3%)
                HighSloppyPhrase       27.77      (2.4%)       27.77      (2.8%)   -0.0% (  -5% -    5%)
                     LowSpanNear       24.53      (5.1%)       24.53      (5.7%)    0.0% ( -10% -   11%)
                 MedSloppyPhrase       51.82      (2.5%)       51.83      (2.6%)    0.0% (  -5% -    5%)
                   OrNotHighHigh       36.18      (1.0%)       36.20      (1.2%)    0.1% (  -2% -    2%)
                 LowSloppyPhrase       96.11      (2.6%)       96.18      (2.8%)    0.1% (  -5% -    5%)
                       MedPhrase      134.06      (2.0%)      134.18      (2.5%)    0.1% (  -4% -    4%)
                          Fuzzy1       64.22      (8.2%)       64.29      (6.3%)    0.1% ( -13% -   15%)
                      AndHighMed      206.17      (1.8%)      206.47      (2.5%)    0.1% (  -4% -    4%)
                        Wildcard       27.28      (2.3%)       27.32      (2.9%)    0.2% (  -4% -    5%)
                     MedSpanNear       36.58      (3.6%)       36.64      (4.1%)    0.2% (  -7% -    8%)
                      AndHighLow      882.47      (3.8%)      884.53      (4.4%)    0.2% (  -7% -    8%)
                         MedTerm      297.22      (1.1%)      297.91      (1.4%)    0.2% (  -2% -    2%)
                    OrHighNotLow       80.63      (2.3%)       80.85      (2.5%)    0.3% (  -4% -    5%)
                    OrHighNotMed       97.77      (2.3%)       98.11      (2.2%)    0.3% (  -4% -    4%)
                    OrNotHighMed      189.36      (1.8%)      190.11      (1.8%)    0.4% (  -3% -    4%)
                         LowTerm      820.55      (2.9%)      830.32      (2.5%)    1.2% (  -4% -    6%)
                      OrHighHigh       26.44      (4.5%)       27.58      (3.5%)    4.3% (  -3% -   12%)
                       OrHighMed       59.16      (4.4%)       62.87      (4.2%)    6.3% (  -2% -   15%)
                       OrHighLow        8.45      (4.5%)        9.10      (4.4%)    7.7% (  -1% -   17%)
        

        I also wanted to test the overhead of propagating approximations to other scorers such as conjunctions, so I modified the tasks from LUCENE-6198 to make them look like +("phrase" term1) +term2 (see attached file), here are the results, I think they are encouraging.

                            TaskQPS baseline      StdDev   QPS patch      StdDev                Pct diff
            AndMedPhraseHighTerm       17.10      (2.3%)       15.47      (1.7%)   -9.5% ( -13% -   -5%)
           AndHighPhraseHighTerm        9.04      (2.0%)        8.95      (1.2%)   -1.0% (  -4% -    2%)
             AndMedPhraseLowTerm      129.01      (5.2%)      147.93      (9.2%)   14.7% (   0% -   30%)
            AndHighPhraseMedTerm       13.55      (2.4%)       15.90      (2.4%)   17.3% (  12% -   22%)
            AndHighPhraseLowTerm       31.49      (2.7%)       38.07      (3.8%)   20.9% (  13% -   28%)
             AndMedPhraseMedTerm       25.39      (2.6%)       37.93      (4.1%)   49.4% (  41% -   57%)
        

        I also added more evil tests to TestApproximationSearchEquivalence.

        Show
        Adrien Grand added a comment - I agree it would be important that our benchmarks track the performance of BS2 as this scorer is probably used pretty often! I worked a bit more on the patch in order to get back some performance. Because things are structured differently, I lost the feature that we confirm at most one clause per doc, but at least performance on simple queries is back (with BS1 disabled this time): TaskQPS baseline StdDev QPS patch StdDev Pct diff Respell 70.77 (3.2%) 69.96 (5.6%) -1.1% ( -9% - 7%) Fuzzy2 57.49 (7.8%) 57.03 (10.1%) -0.8% ( -17% - 18%) AndHighHigh 90.13 (1.7%) 89.61 (2.1%) -0.6% ( -4% - 3%) IntNRQ 7.32 (5.2%) 7.28 (5.3%) -0.5% ( -10% - 10%) OrNotHighLow 824.56 (3.5%) 821.47 (4.0%) -0.4% ( -7% - 7%) HighTerm 73.82 (1.3%) 73.57 (1.1%) -0.3% ( -2% - 2%) LowPhrase 74.18 (1.9%) 73.96 (1.9%) -0.3% ( -4% - 3%) HighSpanNear 43.58 (3.4%) 43.49 (3.7%) -0.2% ( -7% - 7%) Prefix3 72.06 (3.9%) 71.91 (3.8%) -0.2% ( -7% - 7%) PKLookup 265.53 (3.1%) 265.02 (2.8%) -0.2% ( -5% - 5%) HighPhrase 4.24 (4.2%) 4.23 (4.4%) -0.1% ( -8% - 8%) OrHighNotHigh 35.52 (1.5%) 35.51 (1.6%) -0.0% ( -3% - 3%) HighSloppyPhrase 27.77 (2.4%) 27.77 (2.8%) -0.0% ( -5% - 5%) LowSpanNear 24.53 (5.1%) 24.53 (5.7%) 0.0% ( -10% - 11%) MedSloppyPhrase 51.82 (2.5%) 51.83 (2.6%) 0.0% ( -5% - 5%) OrNotHighHigh 36.18 (1.0%) 36.20 (1.2%) 0.1% ( -2% - 2%) LowSloppyPhrase 96.11 (2.6%) 96.18 (2.8%) 0.1% ( -5% - 5%) MedPhrase 134.06 (2.0%) 134.18 (2.5%) 0.1% ( -4% - 4%) Fuzzy1 64.22 (8.2%) 64.29 (6.3%) 0.1% ( -13% - 15%) AndHighMed 206.17 (1.8%) 206.47 (2.5%) 0.1% ( -4% - 4%) Wildcard 27.28 (2.3%) 27.32 (2.9%) 0.2% ( -4% - 5%) MedSpanNear 36.58 (3.6%) 36.64 (4.1%) 0.2% ( -7% - 8%) AndHighLow 882.47 (3.8%) 884.53 (4.4%) 0.2% ( -7% - 8%) MedTerm 297.22 (1.1%) 297.91 (1.4%) 0.2% ( -2% - 2%) OrHighNotLow 80.63 (2.3%) 80.85 (2.5%) 0.3% ( -4% - 5%) OrHighNotMed 97.77 (2.3%) 98.11 (2.2%) 0.3% ( -4% - 4%) OrNotHighMed 189.36 (1.8%) 190.11 (1.8%) 0.4% ( -3% - 4%) LowTerm 820.55 (2.9%) 830.32 (2.5%) 1.2% ( -4% - 6%) OrHighHigh 26.44 (4.5%) 27.58 (3.5%) 4.3% ( -3% - 12%) OrHighMed 59.16 (4.4%) 62.87 (4.2%) 6.3% ( -2% - 15%) OrHighLow 8.45 (4.5%) 9.10 (4.4%) 7.7% ( -1% - 17%) I also wanted to test the overhead of propagating approximations to other scorers such as conjunctions, so I modified the tasks from LUCENE-6198 to make them look like +("phrase" term1) +term2 (see attached file), here are the results, I think they are encouraging. TaskQPS baseline StdDev QPS patch StdDev Pct diff AndMedPhraseHighTerm 17.10 (2.3%) 15.47 (1.7%) -9.5% ( -13% - -5%) AndHighPhraseHighTerm 9.04 (2.0%) 8.95 (1.2%) -1.0% ( -4% - 2%) AndMedPhraseLowTerm 129.01 (5.2%) 147.93 (9.2%) 14.7% ( 0% - 30%) AndHighPhraseMedTerm 13.55 (2.4%) 15.90 (2.4%) 17.3% ( 12% - 22%) AndHighPhraseLowTerm 31.49 (2.7%) 38.07 (3.8%) 20.9% ( 13% - 28%) AndMedPhraseMedTerm 25.39 (2.6%) 37.93 (4.1%) 49.4% ( 41% - 57%) I also added more evil tests to TestApproximationSearchEquivalence.
        Hide
        Robert Muir added a comment -

        This latest patch looks nice at a glance.

        Can you explain this comment a bit more, I'm not sure I understand:

        Because things are structured differently, I lost the feature that we confirm at most one clause per doc
        

        Why do we pass needsScores to these disjunctions? It seems to only optimize the case where someone doesnt needScores but calls freq() anyway, and I don't think we should optimize that. DisjunctionScorer already defers all scoring/freq so I don't think it needs this boolean at all.

        Show
        Robert Muir added a comment - This latest patch looks nice at a glance. Can you explain this comment a bit more, I'm not sure I understand: Because things are structured differently, I lost the feature that we confirm at most one clause per doc Why do we pass needsScores to these disjunctions? It seems to only optimize the case where someone doesnt needScores but calls freq() anyway, and I don't think we should optimize that. DisjunctionScorer already defers all scoring/freq so I don't think it needs this boolean at all.
        Hide
        Adrien Grand added a comment -

        Can you explain this comment a bit more, I'm not sure I understand:

        The first patch worked like conjunctions, the scorer first advanced the approximation and then called nextDoc() on the approximation until it found a document that matches. So when scores were not needed, you could just stop calling "matches()" as soon as one of the clauses that are positionned on the current doc matches. I don't think it's an important optimization but was worth mentioning.

        The new patch is different. In the priority queue, we store both a reference to the sub scorer and its approximation. And the disjunction scorer moves to the next doc by moving the *scorer* in the pq, while the approximation moves to the next candidate by moving the *approximation* in the pq.

        Why do we pass needsScores to these disjunctions? It seems to only optimize the case where someone doesnt needScores but calls freq() anyway.

        I didn't want to optimize anything in particular, but having the freq computed eagerly made the two-phase view a bit easier to implement. I can try to make it lazy again.

        Show
        Adrien Grand added a comment - Can you explain this comment a bit more, I'm not sure I understand: The first patch worked like conjunctions, the scorer first advanced the approximation and then called nextDoc() on the approximation until it found a document that matches. So when scores were not needed, you could just stop calling "matches()" as soon as one of the clauses that are positionned on the current doc matches. I don't think it's an important optimization but was worth mentioning. The new patch is different. In the priority queue, we store both a reference to the sub scorer and its approximation. And the disjunction scorer moves to the next doc by moving the * scorer * in the pq, while the approximation moves to the next candidate by moving the * approximation * in the pq. Why do we pass needsScores to these disjunctions? It seems to only optimize the case where someone doesnt needScores but calls freq() anyway. I didn't want to optimize anything in particular, but having the freq computed eagerly made the two-phase view a bit easier to implement. I can try to make it lazy again.
        Hide
        Robert Muir added a comment -

        The first patch worked like conjunctions, the scorer first advanced the approximation and then called nextDoc() on the approximation until it found a document that matches. So when scores were not needed, you could just stop calling "matches()" as soon as one of the clauses that are positionned on the current doc matches. I don't think it's an important optimization but was worth mentioning.

        OK, so it only impacts when scores are not needed. Thanks. I think its ok to defer.

        I didn't want to optimize anything in particular, but having the freq computed eagerly made the two-phase view a bit easier to implement. I can try to make it lazy again.

        Less tricky is better. I just didnt understand the motivation. We can just add a comment that it simplifies things to do this at the moment?

        Show
        Robert Muir added a comment - The first patch worked like conjunctions, the scorer first advanced the approximation and then called nextDoc() on the approximation until it found a document that matches. So when scores were not needed, you could just stop calling "matches()" as soon as one of the clauses that are positionned on the current doc matches. I don't think it's an important optimization but was worth mentioning. OK, so it only impacts when scores are not needed. Thanks. I think its ok to defer. I didn't want to optimize anything in particular, but having the freq computed eagerly made the two-phase view a bit easier to implement. I can try to make it lazy again. Less tricky is better. I just didnt understand the motivation. We can just add a comment that it simplifies things to do this at the moment?
        Hide
        Robert Muir added a comment -

        In the first chunk of the patch, i think we should pass false to needsScores. This is when we have multiple prohibited clauses and we form a disjunction of them. so scoring is implicitly not needed there:

        @@ -376,10 +376,7 @@
             } else {
               float coords[] = new float[prohibited.size()+1];
               Arrays.fill(coords, 1F);
        -      return new ReqExclScorer(main, 
        -                               new DisjunctionSumScorer(this, 
        -                                                        prohibited.toArray(new Scorer[prohibited.size()]), 
        -                                                        coords));
        +      return new ReqExclScorer(main, new DisjunctionSumScorer(this, prohibited, coords, needsScores));
        
        Show
        Robert Muir added a comment - In the first chunk of the patch, i think we should pass false to needsScores. This is when we have multiple prohibited clauses and we form a disjunction of them. so scoring is implicitly not needed there: @@ -376,10 +376,7 @@ } else { float coords[] = new float[prohibited.size()+1]; Arrays.fill(coords, 1F); - return new ReqExclScorer(main, - new DisjunctionSumScorer(this, - prohibited.toArray(new Scorer[prohibited.size()]), - coords)); + return new ReqExclScorer(main, new DisjunctionSumScorer(this, prohibited, coords, needsScores));
        Hide
        Adrien Grand added a comment -

        You're absolutely right... New patch:

        • freqs are computed lazily again
        • pass needsScores=false to the prohibited clause of the ReqExcl scorer
        • I made TestApproximationSearchEquivalence more evil by also checking that scores are the same if you compute them through the scorer of the approximation (ie. advancing the approximation, calling "matches()" and then "score()" on the Scorer)
        Show
        Adrien Grand added a comment - You're absolutely right... New patch: freqs are computed lazily again pass needsScores=false to the prohibited clause of the ReqExcl scorer I made TestApproximationSearchEquivalence more evil by also checking that scores are the same if you compute them through the scorer of the approximation (ie. advancing the approximation, calling "matches()" and then "score()" on the Scorer)
        Hide
        ASF subversion and git services added a comment -

        Commit 1660180 from Adrien Grand in branch 'dev/trunk'
        [ https://svn.apache.org/r1660180 ]

        LUCENE-6244: DisjunctionScorer propagates two-phase iterators of its sub scorers.

        Show
        ASF subversion and git services added a comment - Commit 1660180 from Adrien Grand in branch 'dev/trunk' [ https://svn.apache.org/r1660180 ] LUCENE-6244 : DisjunctionScorer propagates two-phase iterators of its sub scorers.
        Hide
        ASF subversion and git services added a comment -

        Commit 1660184 from Adrien Grand in branch 'dev/branches/branch_5x'
        [ https://svn.apache.org/r1660184 ]

        LUCENE-6244: DisjunctionScorer propagates two-phase iterators of its sub scorers.

        Show
        ASF subversion and git services added a comment - Commit 1660184 from Adrien Grand in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1660184 ] LUCENE-6244 : DisjunctionScorer propagates two-phase iterators of its sub scorers.
        Hide
        Timothy Potter added a comment -

        Bulk close after 5.1 release

        Show
        Timothy Potter added a comment - Bulk close after 5.1 release

          People

          • Assignee:
            Adrien Grand
            Reporter:
            Adrien Grand
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development