[SERVER-17536] Allow multiple "text" indices on a collection Created: 11/Mar/15  Updated: 28/Dec/23

Status: Backlog
Project: Core Server
Component/s: Text Search
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Henrik Ingo (Inactive) Assignee: Backlog - Query Integration
Resolution: Unresolved Votes: 4
Labels: qi-text-search
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
is duplicated by SERVER-52829 Allow multiple text indices on one co... Closed
is duplicated by SERVER-22755 When does mongodb support many text f... Closed
Related
is related to SERVER-17648 Implement matcher for text predicates Backlog
Assigned Teams:
Query Integration
Participants:
Linked BF Score: 0

 Description   

The manual explains how a compound index that includes a FTS index as one part can significantly optimize queries, since the prefix fields will often narrow down the result set significantly.

http://docs.mongodb.org/manual/tutorial/limit-number-of-items-scanned-for-text-search/

However, creating such a compound index is often not possible, because MongoDB allows only a single FTS index per collection.

For example, to continue the example from the manual, you may want to sometimes search for "red car" across the entire store, without specifying a dept, while other times specifying the dept is possible and could be used to make the query faster. To enable such an optimization it is now necessary, and reasonable, to have both a top-level FTS index as well as a compound dept+FTS index for the same collection.

It seems the current limitation to have only one FTS index is arbitrary and should be lifted to allow using one or more compound indexes. (For clarity, having more than one top-level FTS index is of course not useful - at least if we ignore multiple languages and other advanced cases.)



 Comments   
Comment by Michael Sudnik [ 10/Jul/18 ]

I have multiple examples where being able to define several text indexes (and selecting which one to use when appropriate) would be useful.

  1. Data from multiple users being stored in the same collection, but each with their own "schema". 
  2. A collection having "draft" and "published" fields. I would like to switch between searching within the draft / published data.
Generated at Thu Feb 08 03:44:49 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.