[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: 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: |
| 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. |