[DOCS-12744] [Server] Delete outdated statements on batchSize page Created: 22/May/19  Updated: 30/Oct/23  Resolved: 21/Apr/23

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

Type: Task Priority: Major - P3
Reporter: Tess Avitabile (Inactive) Assignee: Alison Huh
Resolution: Fixed Votes: 0
Labels: quick-win, reopened
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

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

 Description   

Description

The page on batchSize states "Do not use a batch size of 1." and "Specifying 1 or a negative number is analogous to using the limit() method."

However, this is no longer true. Today, batchSize:1 behaves the same as any other positive batchSize.

It does not imply a limit of 1:

> db.c.find().batchSize(1).itcount()
3

And we can see that documents are returned 1 at a time:

2019-05-22T15:45:12.777-0400 I  COMMAND  [conn1] command test.c appName: "MongoDB Shell" command: find { find: "c", filter: {}, batchSize: 1.0, lsid: { id: UUID("e9d60651-adb1-44f8-8833-4e964306aa97") }, $db: "test" } planSummary: COLLSCAN cursorid:7412042066655548514 keysExamined:0 docsExamined:1 numYields:0 nreturned:1 reslen:120 locks:{ ParallelBatchWriter: { acquireCount: { r: 1 } }, ReplicationStateTransition: { acquireCount: { w: 1 } }, Global: { acquireCount: { r: 1 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { R: 1 } }, Mutex: { acquireCount: { r: 1 } } } protocol:op_msg 0ms
2019-05-22T15:45:12.778-0400 I  COMMAND  [conn1] command test.c appName: "MongoDB Shell" command: getMore { getMore: 7412042066655548514, collection: "c", batchSize: 1.0, lsid: { id: UUID("e9d60651-adb1-44f8-8833-4e964306aa97") }, $db: "test" } originatingCommand: { find: "c", filter: {}, batchSize: 1.0, lsid: { id: UUID("e9d60651-adb1-44f8-8833-4e964306aa97") }, $db: "test" } planSummary: COLLSCAN cursorid:7412042066655548514 keysExamined:0 docsExamined:1 numYields:0 nreturned:1 reslen:119 locks:{ ParallelBatchWriter: { acquireCount: { r: 1 } }, ReplicationStateTransition: { acquireCount: { w: 1 } }, Global: { acquireCount: { r: 1 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { R: 1 } }, Mutex: { acquireCount: { r: 1 } } } protocol:op_msg 0ms
2019-05-22T15:45:12.778-0400 I  COMMAND  [conn1] command test.c appName: "MongoDB Shell" command: getMore { getMore: 7412042066655548514, collection: "c", batchSize: 1.0, lsid: { id: UUID("e9d60651-adb1-44f8-8833-4e964306aa97") }, $db: "test" } originatingCommand: { find: "c", filter: {}, batchSize: 1.0, lsid: { id: UUID("e9d60651-adb1-44f8-8833-4e964306aa97") }, $db: "test" } planSummary: COLLSCAN cursorid:7412042066655548514 keysExamined:0 docsExamined:1 numYields:0 nreturned:1 reslen:119 locks:{ ParallelBatchWriter: { acquireCount: { r: 1 } }, ReplicationStateTransition: { acquireCount: { w: 1 } }, Global: { acquireCount: { r: 1 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { R: 1 } }, Mutex: { acquireCount: { r: 1 } } } protocol:op_msg 0ms
2019-05-22T15:45:12.779-0400 I  COMMAND  [conn1] command test.c appName: "MongoDB Shell" command: getMore { getMore: 7412042066655548514, collection: "c", batchSize: 1.0, lsid: { id: UUID("e9d60651-adb1-44f8-8833-4e964306aa97") }, $db: "test" } originatingCommand: { find: "c", filter: {}, batchSize: 1.0, lsid: { id: UUID("e9d60651-adb1-44f8-8833-4e964306aa97") }, $db: "test" } planSummary: COLLSCAN cursorid:7412042066655548514 keysExamined:0 docsExamined:0 cursorExhausted:1 numYields:0 nreturned:0 reslen:94 locks:{ ParallelBatchWriter: { acquireCount: { r: 1 } }, ReplicationStateTransition: { acquireCount: { w: 1 } }, Global: { acquireCount: { r: 1 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { R: 1 } }, Mutex: { acquireCount: { r: 1 } } } protocol:op_msg 0ms

Scope of changes

Impact to Other Docs

MVP (Work and Date)

Resources (Scope or Design Docs, Invision, etc.)



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

Thanks for the confirm david.storch@mongodb.com. We'll leave it open!

 

Comment by David Storch [ 01/Nov/22 ]

Hi sarah.olson@mongodb.com ashley.brown@mongodb.com, I actually think this is still a problem that we should fix, so I've re-opened this ticket. The docs say two conflicting things right now:

Do not use a batch size of 1.

And:

Specifying 1 or a negative number is analogous to using the limit() method.

I don't think either statement is correct. batchSize 1 just acts like a normal batch size these days. I did double check using mongosh that this is true. Here's an example:

Enterprise test> db.c.find().batchSize(1)
[ { _id: 0 }, { _id: 1 }, { _id: 2 }, { _id: 3 }, { _id: 4 } ]

I think we can safely just delete the incorrect information about batchSize:1.

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 David Storch [ 23/May/19 ]

Good catch tess.avitabile!

Comment by Tess Avitabile (Inactive) [ 22/May/19 ]

CC david.storch

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