[DOCS-12428] [Server] add a blurb about the consequences of using limit() and skip() in one query Created: 05/Feb/19  Updated: 30/Oct/23  Resolved: 24/Jul/23

Status: Closed
Project: Documentation
Component/s: manual, Server
Affects Version/s: None
Fix Version/s: Server_Docs_20231030

Type: Task Priority: Major - P3
Reporter: Yulia Genkina (Inactive) Assignee: Christopher Cho
Resolution: Fixed Votes: 0
Labels: quick-win, reopened, server-docs-bug-bash
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:
Days since reply: 1 year, 14 weeks ago

 Description   

Description

It appears that it is unclear from our documentation that when limit() and skip() are used in a query, the order of operation will be the same regardless of the order in which limit and skip are arranged and skip will always be first.

Could that clarification be added somewhere please?

Thank you!

Scope of changes

  • Investigate behavior of cursor.skip when chained with other cursor modifiers
  • Document results in cursor.skip page

Out of scope, but potentially for follow-up : more complete documentation on query plan optimization of cursor modifiers.



 Comments   
Comment by Sarah Olson [ 02/Nov/22 ]

Thanks very much for the detail david.storch@mongodb.com!

Comment by David Storch [ 01/Nov/22 ]

sarah.olson@mongodb.com ashley.brown@mongodb.com this still seems worth doing to me. I could easily imagine a user thinking that .skip().limit() has a different meaning from .limit().skip(), when in fact these two uses of mongosh have the exact same meaning. I'm reopening this ticket.

Comment by Education Bot [ 31/Oct/22 ]

Hello! This ticket has been closed due to inactivity. If you believe this ticket is still important, please reopen it and leave a comment to explain why. Thank you!

Comment by Justin Seyster [ 06/Feb/19 ]

It is definitely true that the order of skip() and limit() don't affect the outcome and execution of the query. These functions only set their respective parameters in the underlying find command. The query planner treats these parameters as an unordered set, so it's not actually possible to specify an order for them.

A skip will be ordered to the front in the sense that a query with skip n and limit m will output m documents and not (m - n) documents (assuming the query returns >= m documents) and in the sense that the optimizer will attempt to skip documents before fetching them for better performance.

In my opinion, talking about the various query parameters in terms of their order may actually be more confusing to users. I think it's better to discuss the effect they have on the query and to clarify how pairs of parameters may interact with each other when it's ambiguous.

(None of this applies to aggregation, where the order of $skip and $limit stages directly affects the output from the pipeline.)

Comment by David Storch [ 06/Feb/19 ]

Perhaps justin.seyster could help to clarify?

Comment by Ravind Kumar (Inactive) [ 05/Feb/19 ]

This kind of feels like it falls into the same sort of category as our docs on aggregation pipeline optimization , but for CRUD. We also don't talk about $skip much.

david.storch@mongodb.com can you recommend someone to talk to about potentially mapping out how the query planner reorders cursor modifiers? For the short term we can just talk about cursor.skip and how it interacts with other cursor methods (i'm hoping it's generally reordered to the front).

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