Performance of the _index field

[Andrew_Carter]

I have a question which I hope is pretty easy to answer fo someone familiar with the ES internals.

The documentation for the _index field states:

The _index is exposed as a virtual field — it is not added to the Lucene index as a real field...

If I specify the _index field in a query that uses an alias spanning multiple indices, is the query optimized such that only the indices in the query's _index actually execute the search? Or do all indices covered by the alias execute the search?

Here is a an example:

POST /_aliases
{
    "actions" : [
        { "add" : { "index" : "index-a-1", "alias" : "index_alias" },
        { "add" : { "index" : "index-a-2", "alias" : "index_alias" },
        { "add" : { "index" : "index-b-1", "alias" : "index_alias" } }
    ]
}

GET index_alias/_search
{
  "query": {
    "bool": {
      "filter": [
        {
          "query_string": {
            "query": "_index:\"index-a-*\""
          }
        }
      ]
    }
  }
}

Our use case can be simplified to the above example. But for context, here is why I'm asking. We are using x-pack roles in Kibana to restrict which indices a user can access. We also want each user to use the same index pattern. So we setup an alias which is used for the Kibana index pattern. We then setup each user role in Kibana to allow read access to the alias, and then further restrict the role using the Granted Documents Query using a query similar to the above example to refine the specific indexes for the role.

We have performance concerns though, about using an alias that may cover hundreds of indexes. Does our Granted Docs Query save us from actually executing search across every index under that alias? If not, is there a different approach that will allow us to efficiently use an identical Kibana index pattern name but change the targeted indices?

Looking at the shard counts in a search response tells me that every index under the alias is involved, which makes sense. I'm hoping that each shard recognizes up-front if the _index doesn't match and computational effort is trivial.