[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: |
|
||||||||
| 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: | |||||||||||||||||||
| 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:
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. |