[SERVER-77449] SBE should support rooted $or queries with clustered indexes Created: 24/May/23  Updated: 30/May/23  Resolved: 25/May/23

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

Type: Improvement Priority: Major - P3
Reporter: Gil Alon Assignee: Gil Alon
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:

 Description   

SERVER-77280 solves a bug where the OR stages do not consider clustered indexes during query planning. This is to unblock using text indexes in clustered collections (SERVER-61259). In the classic engine the children of rooted OR queries can be either index scan or clustered index scans. We investigated supporting this in SBE, found these changes and decided to split the task into 2 tickets.

  1. For plans that use both IXSCAN and CLUSTERED_IXSCAN there is going to be a FETCH stage. However, the FETCH stage has these requirements of its children, such as indexKey, but clustered collection scans don’t have these. These requirements would need to be removed for clustered collection scan nodes. However, if you remove these requirements for this node and the other $or child is an index scan, now the children of the $or query have different slots. This becomes a problem when we try to build a union stage that assumes the children have the same number of slots.
  2. There is a tassert that assumes we only ever have one collection scan, but we can can have a plan now like OR with 2 clustered collection scans.
  3. Clustered collection scans set slots for minRecordId and maxRecordId as environment variables. However, since now we can have 2 clustered collection scans, we face the error of having slots with a duplicate name.


 Comments   
Comment by Gil Alon [ 25/May/23 ]

We found a better solution and do not need to do what is described in the ticket to support rooted $or queries using clustered indexes in SBE. See SERVER-77280 for the solution to the problem described above. 

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