[SERVER-76262] Consider refactoring the collation logic of IDHACK solution for delete command into ParsedDelete Created: 18/Apr/23  Updated: 14/Nov/23

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

Type: Improvement Priority: Major - P3
Reporter: Yoon Soo Kim Assignee: Colin Stolley
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Assigned Teams:
Query Execution
Participants:

 Description   

This is a refactoring ticket.

Currently we don't go through the normal query parsing logic of ParsedDelete for IDHACK solution for delete command inside ParsedDelete::parseRequest().

Instead, we manually compose IDHACK plan inside getExecutorDelete(). As part of this process, we figure out the collator to use.

Given that recently timeseries arbitrary updates/deletes project added a collator resolution logic, we should be able to reuse ParsedDelete's expCtx's collator for IDHACK plan too.

Probably we may want to IDHACK eligibility check into ParsedDelete too and add isIDHackEligible() method and only do the final step like creating IDHackStage and generate the IDHACK plan inside getExecutorDelete()



 Comments   
Comment by Xuan Zhang [ 14/Nov/23 ]

Hi colin.stolley@mongodb.com,

Given your recent work on IDHack, could you please help evaluate if this fits in your current work or PM-3386? Feel free to send it back to backlog if it doesn't fit. Thanks!

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