[SERVER-66903] Ensure that SBE plan cache does not negatively interact with column indexes Created: 31/May/22 Updated: 27/Oct/23 Resolved: 29/Dec/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Ian Boros | Assignee: | Alyssa Clark |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | pm2646-m4 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query Execution
|
| Participants: |
| Description |
|
This ticket covers the work of making queries which use the column index work with the plan cache, OR disabling plan cache usage for such queries. |
| Comments |
| Comment by Alyssa Clark [ 21/Dec/22 ] |
|
For context, one of the issues found previously: https://github.com/10gen/mongo/pull/7821#discussion_r987266879 The fuzzer has found bugs of this sort in the past (i.e. different column scan plans hashing to the same plan cache key), so we likely already have decent coverage on this. I also created find/aggregate overrides that replace match expression leaf values with random constants of various types, run the modified query twice to cache it, then run the original and return its results. I ran the core_column_store_indexes and aggregation_column_store_index_passthrough suites several times with this override (also confirmed that the overrides would have brought out the bug linked above) - no new issues were hit. |