[SERVER-18518] Add filter support for listIndexes Created: 18/May/15 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Index Maintenance |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Scott Hernandez (Inactive) | Assignee: | Backlog - Query Optimization |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Query Optimization
|
||||||||||||||||
| Backwards Compatibility: | Major Change | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
With support for a server applied filter you will be able to get just indexes you care about.
|
| Comments |
| Comment by J Rassi [ 07/Mar/16 ] |
|
I'm reluctant to add any user-facing functionality to the server that's not supported by a compelling use case. More user-facing functionality = more code to write/review/maintain, more to document, more to remember. I suspect that if we'd decided not to add the "filter" option to listCollections and instead exposed an option called "name" to do exact matches on, then we wouldn't be maintaining a tiny query optimizer in list_collections.cpp. That said, I don't have a particularly strong opinion here. If you think this functionality is e.g. particularly helpful for testing, feel free to reschedule it. |
| Comment by Max Hirschhorn [ 05/Mar/16 ] |
|
The $indexStats stage in aggregation only returns the index name and key pattern. This may be sufficient for the use-case described in this ticket's description, but it doesn't represent parity with what an arbitrary query on the system.indexes collection was capable of. jason.rassi, why are we reluctant to have a MatchExpression in the "listIndexes" command similar to what we have with the "listCollections" command already? |
| Comment by Charlie Swanson [ 26/Feb/16 ] |
|
As a workaround, you can use the $indexStats aggregation stage, and then apply whatever further processing you need. Note that this doesn't include the version field though. |
| Comment by Charlie Swanson [ 11/Dec/15 ] |
|
scotthernandez, we're tempted to close this as won't fix, since there are at most 64 indexes, and you can filter in the application code. Can you explain why you need this functionality? |