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

Avoid normalizing partialFilterExpression when creating a new index

    • Type: Icon: Task Task
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.9.0
    • Affects Version/s: None
    • Component/s: Index Maintenance
    • Labels:
      None
    • Fully Compatible
    • Query Execution 2021-02-22, Query Execution 2021-03-08, Query Execution 2021-03-22

      In SERVER-25023, we introduced improved normalization of index specs such that partialFilterExpression and wildcardProjection fields are converted to a canonical representation on index creation. This means that logically identical filters will appear the same in the catalog and in the output of listIndexes; before this ticket, only the collation field was normalized in this way.

      However, this turns out to have caused some problems for the Cloud team. The Automation agent is responsible for taking an index configuration from the user and continuously ensuring that all nodes match these settings. They do so by issuing listIndexes and comparing the index specs against the desired set of indexes. Because the normalized partialFilterExpression can appear very different than the filter that the user specified, this means that Automation will need to be able to translate between the raw and normalized formats. This is not a trivial task, and will be fragile if we decide to allow additional expressions to be used in the partialFilterExpression or change how we optimize MatchExpression trees.

      In practice, when comparing two indexes for equivalence, we do not actually rely on the serialized form; we parse the existing and candidate partialFilterExpressions and use MatchExpression::equivalent. It should therefore be safe to remove the normalization of partialFilterExpression, which means that Cloud can continue to expect the partialFilterExpression of existing indexes to exactly match the user's request. We should retain the normalization of wildcardProjection, though, since this will likely be leveraged by SERVER-47659 and is trivial to translate on Cloud's side.

            Assignee:
            bernard.gorman@mongodb.com Bernard Gorman
            Reporter:
            bernard.gorman@mongodb.com Bernard Gorman
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: