Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-77449

SBE should support rooted $or queries with clustered indexes

    XMLWordPrintableJSON

Details

    • Icon: Improvement Improvement
    • Resolution: Duplicate
    • Icon: Major - P3 Major - P3
    • None
    • None
    • None
    • None

    Description

      SERVER-77280 solves a bug where the OR stages do not consider clustered indexes during query planning. This is to unblock using text indexes in clustered collections (SERVER-61259). In the classic engine the children of rooted OR queries can be either index scan or clustered index scans. We investigated supporting this in SBE, found these changes and decided to split the task into 2 tickets.

      1. For plans that use both IXSCAN and CLUSTERED_IXSCAN there is going to be a FETCH stage. However, the FETCH stage has these requirements of its children, such as indexKey, but clustered collection scans don’t have these. These requirements would need to be removed for clustered collection scan nodes. However, if you remove these requirements for this node and the other $or child is an index scan, now the children of the $or query have different slots. This becomes a problem when we try to build a union stage that assumes the children have the same number of slots.
      2. There is a tassert that assumes we only ever have one collection scan, but we can can have a plan now like OR with 2 clustered collection scans.
      3. Clustered collection scans set slots for minRecordId and maxRecordId as environment variables. However, since now we can have 2 clustered collection scans, we face the error of having slots with a duplicate name.

      Attachments

        Activity

          People

            gil.alon@mongodb.com Gil Alon
            gil.alon@mongodb.com Gil Alon
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: