[SERVER-45918] Optimized code path for "simple" sort operations in PlanStage layer Created: 31/Jan/20  Updated: 29/Oct/23  Resolved: 13/Feb/20

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

Type: Improvement Priority: Major - P3
Reporter: David Storch Assignee: David Storch
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Problem/Incident
Related
Backwards Compatibility: Fully Compatible
Sprint: Query 2020-02-10, Query 2020-02-24
Participants:
Linked BF Score: 0

 Description   

The current implementation of SortStage is fully general in the sense that it can handle sorting all of the data that can be associated with a WorkingSetMember. This includes:

  • Sorting WorkingSetMembers that represent index keys.
  • Carrying RecordIds alongside the documents being sorted. This is necessary to support findAndModify with a sort. The RecordId is subsequently used by findAndModify to identify the document to update or delete.
  • Carrying metadata alongside the documents being sorted. This could be textScore metadata, geoNear distance metadata, or sortKey metadata, for example.

This all comes with a cost. We can avoid sorting this unnecessary data in many cases, e.g. for sort operations other than findAndModify which don't involve metadata, and where the data has been fetched. This is done by introducing a new variant of SortStage which sorts simple BSON objects instead of entire WorkingSetMembers. An early prototype of this approach shows significant performance gains on several sort-related benchmarks.



 Comments   
Comment by Githook User [ 13/Feb/20 ]

Author:

{'name': 'David Storch', 'username': 'dstorch', 'email': 'david.storch@mongodb.com'}

Message: SERVER-45918 Add SortStageSimple.

This new sort implementation can be used in lieu of the
pre-existing general implementation when certain special
conditions are met:

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