[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:
Depends
is depended on by DRIVERS-244 get index by name Closed
Duplicate
is duplicated by SERVER-21888 Provide operation to determine if an ... Closed
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.

> db.a.runCommand("listIndexes")
{
	"cursor" : {
		"id" : NumberLong(0),
		"ns" : "test.$cmd.listIndexes.a",
		"firstBatch" : [
			{
				"v" : 1,
				"key" : {
					"_id" : 1
				},
				"name" : "_id_",
				"ns" : "test.a"
			},
			{
				"v" : 1,
				"key" : {
					"a" : 1
				},
				"name" : "a_1",
				"ns" : "test.a"
			},
			{
				"v" : 1,
				"key" : {
					"b" : 1
				},
				"name" : "b_1",
				"ns" : "test.a"
			}
		]
	},
	"ok" : 1
}
> db.a.runCommand("listIndexes", {filter:{"key.a":{$exists:1}}})
{
	"cursor" : {
		"id" : NumberLong(0),
		"ns" : "test.$cmd.listIndexes.a",
		"firstBatch" : [
			{
				"v" : 1,
				"key" : {
					"a" : 1
				},
				"name" : "a_1",
				"ns" : "test.a"
			}
		]
	},
	"ok" : 1
}



 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?

Generated at Thu Feb 08 03:47:56 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.