Uploaded image for project: 'Jackrabbit Oak'
  1. Jackrabbit Oak
  2. OAK-5449

Cost calculation for one matching property restriction/sorting results in selection of wrong index

    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Open
    • Major
    • Resolution: Unresolved
    • 1.4.10
    • None
    • lucene
    • None

    Description

      The method IndexPlanner.getPlanBuilder() for Lucene indexes contains at the end an algorithm that calculates a costPerEntryFactor. If there is no restriction property or sort property the factor will be the same like for one restriction property or sort property.

      If there are two indexes for which the cost is calculated, the cost must not be the same. E.g. if there is a large result set that can be sorted with one index but not with the other index, the index that supports sorting should be used.

      The following code snippet:

      if (costPerEntryFactor == 0) {
      costPerEntryFactor = 1;
      }

      should be changed to something like this (assuming costPerEntryFactor will be changed to double value and will be rounded after division at the end of the method):

      if (costPerEntryFactor == 1.0) {
      // one matching restriction or sort property
      costPerEntryFactor = 1.5;
      }
      else if (costPerEntryFactor == 0.0) {
      // no matching restriction or sort property
      costPerEntryFactor = 1.0;
      }

      Furthermore, since the found indexes are stored in a hashed collection, the order of the index evaluation and the resulting index (when cost is the same for more than one lucene based index) is non deterministic. This increases the issue with the code above.

      Attachments

        Issue Links

          Activity

            People

              chetanm Chetan Mehrotra
              vschmidt Volker Schmidt
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated: