[SERVER-66459] Explode for sort caches incorrect parameterized plans Created: 13/May/22  Updated: 29/Oct/23  Resolved: 04/Jul/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 6.0.0-rc5, 6.1.0-rc0
Fix Version/s: 6.1.0-rc0

Type: Bug Priority: Major - P3
Reporter: David Storch Assignee: Anton Korshunov
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Related
related to SERVER-67576 Make parameterized explode for sort p... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v6.0
Steps To Reproduce:

The second assertion in this repro script fails against a server that has SBE and the SBE plan cache enabled:

(function() {
"use strict";
 
const coll = db.c;
coll.drop();
 
assert.commandWorked(coll.createIndex({a: 1, b: 1, c: 1}));
assert.commandWorked(coll.insert({a: 2, b: 3}));
 
// Create an SBE plan cache.
assert.eq(0, coll.find({a: {$eq: 2}, b: {$in: [99, 4]}}).sort({c: 1}).itcount());
 
// Run a query that reuses the cache entry and should return the one document in the collection.
assert.eq(1, coll.find({a: {$eq: 2}, b: {$in: [3, 4]}}).sort({c: 1}).itcount());
}());

Sprint: QO 2022-05-16, QO 2022-05-30, QO 2022-06-13, QO 2022-06-27, QO 2022-07-11
Participants:

 Description   

The QueryPlanner has some special logic called "explode for sort" which attempts to convert one index scan into a sorted merge of several index scans in order to avoid a blocking SORT operation. This logic does not interact correctly with auto-parameterization.

When an auto-parameterized predicate is converted to index bounds in the IndexBoundsBuilder, we record this fact inside an IntervalEvaluationTree, or IET. The IET allows us to recompute the index bounds when the indexed plan is bound to new parameter values. The explode for sort path appears to discard the IETs attached to the original IndexScanNode. This results in the downstream logic treating the index scan as though it is not parameterized, embedding the KeyString constants for the high and low keys directly into the plan. When the plan is recovered from the cache for a query with different constants, this can result in incorrect or missing query results.



 Comments   
Comment by Githook User [ 29/Jun/22 ]

Author:

{'name': 'Anton Korshunov', 'email': 'anton.korshunov@mongodb.com', 'username': 'antkorsh'}

Message: SERVER-66459 Explode for sort caches incorrect parameterized plans
Branch: master
https://github.com/mongodb/mongo/commit/11aa6d3c5166f0e8dcaefca691d303b9c0af3dc9

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