[SERVER-63682] PlanCacheKey Factory should decide how to encode query shape, not CanonicalQuery Created: 15/Feb/22  Updated: 29/Oct/23  Resolved: 04/Apr/23

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

Type: Task Priority: Major - P3
Reporter: Alexander Ignatyev Assignee: Anton Korshunov
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: QO 2022-05-02, QO 2022-05-16, QO 2022-07-25, QO 2022-08-08, QO 2022-08-22, QO 2022-09-05, QO 2022-09-19, QO 2022-10-03, QE 2022-10-17, QO 2023-03-06, QO 2023-03-20, QO 2023-04-03, QO 2023-04-17
Participants:

 Description   

plan_cache_key_factory asks CanonicalQuery to encode the query's shape: https://github.com/10gen/mongo/blob/86473072ba8f4765d9d164c44df5e55b11cb46e3/src/mongo/db/query/plan_cache_key_factory.cpp#L80

The issue here is that plan_cache_key_factory already knows which PlanCacheKey it should create - Classic or SBE, nevertheless, CanonicalQuery makes additional checks and decides itself how to encode the shape using SBE or Classic way:

https://github.com/10gen/mongo/blob/86473072ba8f4765d9d164c44df5e55b11cb46e3/src/mongo/db/query/canonical_query.cpp#L530-L534

This potentially may lead to bugs when SBE PlanCacheKey might be created using classic encoding algorithm and vice versa.



 Comments   
Comment by Githook User [ 04/Apr/23 ]

Author:

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

Message: SERVER-63682 PlanCacheKey Factory should decide how to encode query shape
Branch: master
https://github.com/mongodb/mongo/commit/1bd8ed2ebea20b7b85ee8d2682949797b4bbfa28

Comment by Anton Korshunov [ 22/Feb/23 ]

david.storch@mongodb.com There were two PRs for this ticket, we decided to delay the first one and merge the second. The reason for delaying it was that there was some future work planned which would allow to significantly simplify implementation of the idea proposed in patch 1. I need to remember all details but I'm planning to spend some time next sprint on this ticket and will send another update (or most likely a new PR).

Comment by David Storch [ 21/Feb/23 ]

anton.korshunov@mongodb.com I'm confused about the status of this ticket – can you clarify? I apparently approved a PR in May 2022, but the ticket is still open and the githook didn't add a comment with any associated git commits.

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