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

Wrong optimization for joins with ISDESCENDANTNODE conditions

Attach filesAttach ScreenshotVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 1.0.8, 1.1.2
    • 1.0.9, 1.1.3
    • core, query
    • None

    Description

      Joins with ISDESCENDANTNODE condition are incorrectly optimized when the join is executed in the reverse order: instead of a path condition of the form "all parents", a path condition of the form "parent" is used. That means, the first selector only traverse the parent node, when the TraversingIndex is used, instead of all possible parent nodes. As of now, there is no path condition of the form "all parents".

      This affects both SQL-2 and XPath queries.

      It is a problem if the join is reversed due to lower potential cost, which is so far seldom, and it looks like only in combination with the TraversingIndex. There are some existing tests that only fail when the new cost estimation is used (OAK-1907). Still, it is theoretically possible that existing code is affected (even without OAK-1907).

      Attachments

        Activity

          This comment will be Viewable by All Users Viewable by All Users
          Cancel

          People

            thomasm Thomas Mueller
            thomasm Thomas Mueller
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Slack

                Issue deployment