[SERVER-75294] Investigate slowness of sharded $lookup Created: 26/Mar/23  Updated: 07/Aug/23  Resolved: 07/Aug/23

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

Type: Task Priority: Major - P3
Reporter: Katya Kamenieva Assignee: Hana Pearlman
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-77427 Avoid going through the network when ... Closed
Related
related to SERVER-58727 Perform local operation when AsyncReq... Closed
related to SERVER-75732 Cache $lookup single solution inner q... Closed
is related to SERVER-77427 Avoid going through the network when ... Closed
Sprint: QO 2023-05-15, QO 2023-05-29, QO 2023-06-12, QO 2023-06-26, QO 2023-07-10, QO 2023-07-24, QO 2023-08-07, QO 2023-08-21
Participants:

 Description   

When both collections are sharded, lookup queries are ~2x slower than for non-sharded collections.
Let's understand what is the cause of this impact on performance.



 Comments   
Comment by Hana Pearlman [ 04/Aug/23 ]

Belatedly closing this ticket now, because we don't intend to do any more work on it. The improvement to skip the network for a $lookup subpipeline when a shard is targeting only itself (SERVER-77427) is scheduled to be completed as part of PM-3229, which is in progress now. When that ticket is complete, we expect to see improvements in the targeted perf workloads merged in PERF-4152. Another improvement ticket, SERVER-75732, is intended to be investigated in the next quarter.

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