[SERVER-79041] [CQF] Decide how to deal with creating a global SBE slot for ShardFilterer Created: 17/Jul/23  Updated: 29/Oct/23  Resolved: 25/Aug/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 7.1.0-rc0

Type: Improvement Priority: Major - P3
Reporter: Richard Hausman (Inactive) Assignee: Ben Shteinfeld
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Query Optimization
Backwards Compatibility: Fully Compatible
Sprint: QO 2023-09-04
Participants:

 Description   

There are a couple of scenarios in which the necessity of creating an SBE slot depends on the characteristics of an SBE plan (for example, $now and shardFilter). This ticket will focus on shardFilter, but it remains a question for other scenarios.

There are a couple of proposed solutions on how best to handle this scenario:

  1. (Currently used for shardFilterer) Globally allocate and fill a slot before running ABT lowering, such as in cqf_get_executor.cpp. These slots may not end up being used, but the solution is simple and unlikely to cause issues/bugs in the future. Note (idea from Nick): we could also allocate these slots in the constructor of RuntimeEnvironment.
  2. Make RuntimeEnvironment non-const and create the slots as-needed from within the lowering (or other) code, when it becomes clear that the slot is needed. This is nice because it creates the slot if it's needed and makes intuitive sense, but in some scenarios the need for it might be optimized out, and it requires making RuntimeEnvironment non-const.
  3. Prior to execution of the SBE plan, perform a "second-pass" walk in which we analyze the plan, see if a shard filterer is called for, and create the slot if so. This is nice because everything happens in one place and the slot is created if and only if needed, but it requires a second round of walking which could have performance implications.

 

The task of this ticket is to decide what the best solution is and implement it for shard filtering, then to file a ticket to make the improvement in the other analogous cases.



 Comments   
Comment by Githook User [ 25/Aug/23 ]

Author:

{'name': 'Ben Shteinfeld', 'email': 'ben.shteinfeld@mongodb.com', 'username': 'bshteinfeld'}

Message: SERVER-79041 Only register ShardFilterer slot in global environment if collection is sharded

This prevents queries against unsharded collections from unnecessarily registering a slot for the ShardFilterer. After this patch, the only situation in which a query would have an unused ShardFilterer is if the collection is sharded and the query contains an equality predicate on the shard key.
Branch: master
https://github.com/mongodb/mongo/commit/712857124bbebbe153e7b4140f71e4a48edde7b1

Generated at Thu Feb 08 06:39:55 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.