[DOCS-2208] Text search covering behavior incorrectly documented Created: 07/Nov/13  Updated: 06/Feb/14  Resolved: 06/Feb/14

Status: Closed
Project: Documentation
Component/s: manual
Affects Version/s: None
Fix Version/s: v1.3.0

Type: Bug Priority: Major - P3
Reporter: Tyler Brock Assignee: Kay Kim (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by DOCS-2565 Comment on: "manual/tutorial/return-t... Closed
Participants:
Days since reply: 10 years, 2 weeks ago

 Description   

[ed: original title "I believe there is no such thing as a covered text query."]

I'm not sure about this so we need to confirm with mathias but I believe this page has inaccurate information.

http://docs.mongodb.org/manual/tutorial/return-text-queries-using-only-text-index/

According to redbeard0531 this feature does not actually allow for covered queries as we always load the documents within the text search code path so attempts to achieve a covered text query with an additional field will actually increase index sizes (which will make query times slower) and provide no benefit.



 Comments   
Comment by Kay Kim (Inactive) [ 06/Feb/14 ]

change only for v2.4

Comment by Githook User [ 06/Feb/14 ]

Author:

{u'username': u'kay-kim', u'name': u'kay', u'email': u'kay.kim@10gen.com'}

Message: DOCS-2208 v2.4 text search covering behavior
Branch: v2.4
https://github.com/mongodb/docs/commit/eca17b02641775505a1f710ba04364577246e45a

Comment by J Rassi [ 12/Nov/13 ]

The covered index matching behavior does work, but the linked page doesn't correctly describe the feature.

It is correct that the text search command always loads in the final result set from the collection. However, a compound text index can be used to accelerate text searches that specify a filter, by providing covering behavior for that filter during the index scan (but note this behavior is useless for searches that contain phrases or negated terms, since those force document fetches during the index scan). See the difference in nscannedObjects in these two searches:

> db.collection.ensureIndex({comments: "text", username: 1})
> db.collection.insert({comments: ["hello world"], username: "sally", city: "new york"})
> db.collection.runCommand("text", {search: "hello world", filter: {city: "new york"}}).stats
{
	"nscanned" : 2,
	"nscannedObjects" : 1,
	"n" : 1,
	"nfound" : 1,
	"timeMicros" : 113
}
> db.collection.runCommand("text", {search: "hello world", filter: {username: "sally"}}).stats
{
	"nscanned" : 2,
	"nscannedObjects" : 0,
	"n" : 1,
	"nfound" : 1,
	"timeMicros" : 91
}
>

Relatedly, the nscannedObjects field is incorrectly documented. The correct description is: "The nscannedObjects field returns the total number of documents scanned to satisfy the provided filter." Arguably the bug is in the code rather than the docs, but (considering the looming deprecation date for the text command) it's unlikely to be changed.

Generated at Thu Feb 08 07:42:54 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.