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

Omit unnecessary cfilter PlanStage in parameterized SBE index plans

    • Type: Icon: Task Task
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 8.0.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • Labels:
    • Query Optimization
    • Fully Compatible

      In the MixedWorkloads genny workload (high-value workload), there are queries of the form


      findOne({id: <int>})

      Note that the field id is not _id, but does have a secondary index.


      This leads to a plan like

      slots: '$$RESULT=s11 env: { s5 = Nothing, s3 = 1706728396314 (NOW), s10 = {"id" : 1}, s1 = TimeZoneDatabase(Asia/Dhaka...Africa/Addis_Ababa) (timeZoneDB), s2 = Nothing (SEARCH_META), s6 = Nothing
      [3] limit 1
      [2] nlj inner [] [s4, s7, s8, s9, s10]
             [1] cfilter {(exists(s5) && exists(s6))}
             [1] ixseek s5 s6 s9 s4 s7 s8 [] @"f86e4a9b-d340-47b9-9936-c2c880428773" @"id_1" true
              [2] limit 1
              [2] seek s4 s11 s12 s7 s8 s9 s10 [] @"f86e4a9b-d340-47b9-9936-c2c880428773" true false 

      The constant filter stage above the ixseek does not appear to be necessary since we know that the bounds will be constants and parameterized in the query.

      This be obsoleted by SERVER-86237, but it might help with queries not covered by that ticket.

            hana.pearlman@mongodb.com Hana Pearlman
            ben.shteinfeld@mongodb.com Ben Shteinfeld
            0 Vote for this issue
            4 Start watching this issue