Investigate and remove workaround for kOther match expression renames in change stream router pipeline optimization

XMLWordPrintableJSON

    • Type: Task
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Query Optimization
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      There's a TODO here that implements a workaround for pushing $match stages ahead of internal change stream router pipeline stages. The workaround always allows $match to be pushed before these stages without performing rename checks, based on the assumption that these stages "do not access or modify any paths in the input document."

      The code currently bypasses normal dependency analysis for these change stream router stages:

      • $_internalChangeStreamEnsureResumeTokenPresent
      • $_internalChangeStreamHandleTopologyChange
      • $_internalChangeStreamHandleTopologyChangeV2

      Problem. Match expressions in the MatchCategory::kOther category don't have complete renaming support implemented in hasOnlyRenameableMatchExpressionChildrenImpl().

      • $where expressions
      • INTERNAL_SCHEMA_ALLOWED_PROPERTIES
      • INTERNAL_SCHEMA_OBJECT_MATCH

      For most kOther expressions, the default case returns false, preventing the match from being pushed down before stages that rename paths.

      This ticket should investigate:

      1. Are change stream router stages truly path-neutral?

      • Do these stages really never access or modify any paths in the input document?
      • Review the implementation of each stage to verify this assumption still holds
      • Check if this has changed since the workaround was introduced

      2. What is the actual correlation between kOther renames and change streams?

      • Why is this workaround specifically needed for change streams but not other stages?
      • What failures occur if we remove the workaround?

      3. Can we implement proper rename checks instead?

      • Would it be more correct to implement rename logic for the kOther expressions that need it?
      • Or is the workaround valid because these stages genuinely don't need rename checks?
      • What's the performance/correctness tradeoff?

       

      Original ticket description

      There is a TODO in the codebase referencing a resolved ticket which is assigned to you.

      Please follow this link to see the lines of code referencing this resolved ticket:
      https://github.com/10gen/mongo/search?q=SERVER-55492&type=Code

      The next steps for this ticket are to either remove the outdated TODO or follow the steps in the TODO if it is correct. If the latter, please update the summary and description of this ticket to represent the work you're actually doing.

            Assignee:
            Matt Olma
            Reporter:
            xgen-buildbaron-user
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: