[SERVER-35891] Add failpoint to disable aggregation optimizations Created: 28/Jun/18  Updated: 29/Oct/23  Resolved: 25/Jul/18

Status: Closed
Project: Core Server
Component/s: Aggregation Framework
Affects Version/s: None
Fix Version/s: 4.1.2

Type: Improvement Priority: Major - P3
Reporter: David Bradford (Inactive) Assignee: Varun Arora
Resolution: Fixed Votes: 0
Labels: tig-skip-pointing
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
related to SERVER-42197 Expose a per-query flag to disable ag... Closed
Backwards Compatibility: Fully Compatible
Sprint: TIG 2018-07-16, TIG 2018-07-30
Participants:

 Description   

In order to test for errors caused by optimizations in the aggregation pipeline, we will add a failpoint to the aggregation pipeline that will disable optimization. This will allow the aggregation fuzzer to run queries against a version of mongo with optimizations turned on and one with optimizations turned off to compare their results.



 Comments   
Comment by Githook User [ 25/Jul/18 ]

Author:

{'name': 'Varun Arora', 'email': 'varun.arora@10gen.com', 'username': 'avarun42'}

Message: SERVER-35891 add failpoints to disable aggregation optimizations
Branch: master
https://github.com/mongodb/mongo/commit/47a7e08012f57e471dff60d1933192786b54e50d

Comment by Max Hirschhorn [ 02/Jul/18 ]

david.storch, david.bradford, I was thinking we'd just do #1 to skip calling Pipeline::optimize() but would want to also know if #2 of skipping MatchExpression::optimize() has implications on whether a $match stage can be split, reordered, or coalesced. If it can, then I think we'll want to do that one as well. #3 of always using a collection scan feels closer to a separate fuzzing project of comparing the query results of all explain plans.

Comment by David Storch [ 29/Jun/18 ]

david.bradford, which set of optimizations specifically do we want to be able to inhibit? I could imagine the following:

  1. Turn off Pipeline::optimize().
  2. Turn off MatchExpression::optimize().
  3. Circumvent access planning entirely, and just use a collection scan.

Which of these are planned as part of the aggregation fuzzer work? Also, please CC the query team on any relevant code reviews in this area.

Generated at Thu Feb 08 04:41:21 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.