[SERVER-57579] DocumentSourceSequentialCache doesn't clone, ruining non-correlated $lookup pipeline caching in sharded deployments Created: 09/Jun/21  Updated: 15/Jun/21  Resolved: 15/Jun/21

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 4.4.0, 5.0.0-rc0
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Charlie Swanson Assignee: Ted Tuckman
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
duplicates SERVER-57168 pipeline->clone() breaks on pipelines... Closed
Problem/Incident
is caused by SERVER-45538 Implement and test shard version retr... Closed
Related
related to SERVER-57705 DocumentSourceSequentialCache can win... Backlog
related to SERVER-57168 pipeline->clone() breaks on pipelines... Closed
related to SERVER-57668 Cache chunk bounds as an array in res... Closed
is related to SERVER-57483 Results from $lookup stage are not ca... Closed
is related to SERVER-30399 Add caching for $lookup non-correlate... Closed
Operating System: ALL
Sprint: Query Optimization 2021-06-28
Participants:

 Description   

As outlined in SERVER-57483, the serialization code isn't appropriate as a mechanism to clone this stage. We should investigate a more robust way to distinguish the two use cases of serializing to the shards and serializing for being copied.

The impact of this problem is quite large. It means that your performance of a non-correlated $lookup might degrade when you move from a replica set to a sharded cluster.



 Comments   
Comment by Ted Tuckman [ 15/Jun/21 ]

Closing this in favor of fixing clone() under SERVER-57168, as resharding will be fixing this case in a linked ticket.

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