Skip to content

Commit 1dd4f9a

Browse files
author
Sam Kleinman
committed
DOCS-330 final round of comments on the indexing documents
1 parent 2e6a1b8 commit 1dd4f9a

File tree

4 files changed

+16
-15
lines changed

4 files changed

+16
-15
lines changed

draft/administration/indexes.txt

Lines changed: 6 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -261,7 +261,7 @@ Consideration
261261
~~~~~~~~~~~~~
262262

263263
:ref:`Background index creation operations
264-
<index-creation-background>` became *foreground* indexing operations
264+
<index-creation-background>` become *foreground* indexing operations
265265
on :term:`secondary` members of replica sets. These foreground
266266
operations will block all replication on the secondaries, and don't
267267
allow any reads. As a result in most cases use the following procedure
@@ -282,7 +282,7 @@ Procedure
282282
:option:`--replSet <mongod --replSet>` option. Allow replication
283283
to catch up on this member.
284284

285-
#. Replete this operation on all of the remaining secondaries.
285+
#. Repeat this operation on all of the remaining secondaries.
286286

287287
#. Run :func:`rs.stepDown()` on the :term:`primary` member of the
288288
set, and then repeat this procedure on the former primary.
@@ -296,11 +296,9 @@ Procedure
296296

297297
.. note::
298298

299-
This procedure *does* block indexing on one member of the
300-
replica set at a time. However, the foreground indexing
301-
operation is more efficient than the background index operation,
302-
and will only affect one secondary at a time rather than *all*
303-
secondaries at the same time.
299+
This procedure *does* take one member out of the replica set at a
300+
time. However, this procedure will only affect one member of the
301+
set at a time rather than *all* secondaries at the same time.
304302

305303
.. [#different-port] By running the :program:`mongod` on a different
306304
port, you ensure that the other members of the replica set and all
@@ -357,7 +355,7 @@ Monitoring and Controlling Index Building
357355
completion of DOCS-162
358356

359357
To see the status of the indexing processes, you can use the
360-
:func:`db.currentOP()` method in the :program:`mongo` shell. The value
358+
:func:`db.currentOp()` method in the :program:`mongo` shell. The value
361359
of the ``query`` field and the ``msg`` field will indicate if the
362360
operation is an index build. The ``msg`` field also indicates the
363361
percent of the build that is complete.

draft/applications/indexes.txt

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -118,7 +118,7 @@ results. For example:
118118
db.collection.find( { a:5, b:3, c:{ $lt:2 }, d:{ $gt:4 } } ).sort( { c:1 } )
119119

120120
However, the following query operations would not be able to sort
121-
data using the index:
121+
the results using the index:
122122

123123
.. code-block:: javascript
124124

draft/core/indexes.txt

Lines changed: 8 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -410,11 +410,11 @@ construction:
410410
members of the set. All indexing operations on secondaries block
411411
replication.
412412

413-
To rebuild large indexes on secondaries the best approach is to
413+
To build large indexes on secondaries the best approach is to
414414
restart one secondary at a time in "standalone" mode and build the
415-
index. When the index is rebuilt, restart as a member of the
415+
index. After building the index, restart as a member of the
416416
replica set, allow it to catch up with the other members of the
417-
set, and then rebuild the index on the next secondary. When all the
417+
set, and then build the index on the next secondary. When all the
418418
secondaries have the new index, step down the primary, restart it
419419
as a standalone, and build the index on the former primary.
420420

@@ -563,9 +563,12 @@ when the query must filter along another dimension.
563563
miles of a given point *and* have a type field value of "museum," a
564564
haystack index would be provide the best support for these queries.
565565

566-
Haystack indices allow you to tune your bucket size to the
566+
Haystack indexes allow you to tune your bucket size to the
567567
distribution of your data, so that in general you search only very
568-
small regions of 2d space for a particular kind of document.
568+
small regions of 2d space for a particular kind of document. These
569+
indexes are not suited for finding the closest documents to a
570+
particular location, when the closest documents are far away compared
571+
to bucket size.
569572

570573
Index Limitations
571574
-----------------
Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
11
.. note::
22

3-
To rebuild indexes for a :term:`replica set` see
3+
To build or rebuild indexes for a :term:`replica set` see
44
:ref:`index-rebuilding-replica-sets`.

0 commit comments

Comments
 (0)