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

sparse compound index should really be sparse



    • Type: Improvement
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Indexing
    • Labels:
    • Backwards Compatibility:
      Fully Compatible
    • Case:


      I've always believed from documentation that only single field sparse index were supported.
      Doing quick testing, it turns out:

      • compound sparse index creates fine
      • the behavior is that it is only sparse if all fields are non existent

      I feel like the behavior is not useful at all: it's rare that all fields are absent and thus it mostly behaves like a non-sparse.
      The more common use case is as follows:

      • a sparse field tells if doc should be included in index
      • compound on other fields to do further matching an sorting, like time etc

      Say I'm working on reconciliation software: 99% of my records are matched and 1% non matched.
      I need to do fast operations on non-matched items that may include complex matching and sorting.
      Right now if I want to compound the index, all 100% records will be in index tree.
      Ideally I just have a sparse flag "unmatched: true" and can compound freely

      { unmatched:1, customerId: 1, date: 1 }

      and obtain an index that's 99% smaller.
      Today the only solution is to somehow encode information into the "unmatched" field.


          Issue Links



              • Votes:
                12 Vote for this issue
                13 Start watching this issue


                • Created: