Mongo View Not Showing Same Indexing Speed Improvement As in Targeted Collection - mongodb

Question

I have created a mongo view that basically targets documents on an "accounts" collection - specifically where the value for "transactions.amount.balance" is greater than zero. So that looks like this:
{"transactions.amounts.balance": { $gt : 0 }}
Now, because results took a long time to return, I have added an index on this field in the collection this view works with. Subsequently, when I then run this query on the collection, the results now return much more quickly -- like less than a second instead of 9 seconds prior to adding the index.
However, that said, I don't seem to be noticing the same performance improvement in the mongo view I've created, which, again, among other things, recreates this same query on the same collection.
My understanding is that a view will inherit all of the indexes that have been created on the collection it targets. So, if that's the case, why am I not seeing any kind of performance improvement in the mongo view? Am I missing something?
By the way, when I check the input and output of each stage of my aggregation pipeline, sure enough, this is the one that takes about 9 seconds to return results:
{ "transactions.amounts.balance" : { "$gt" : 0.0 } }
Why is this query step so much slower in my view than when run directly on the collection it targets? Is there something else I can to help speed up the execution of this query step?
Here are the first few steps of the aggregation pipeline in my mongo view:
db.accounts.aggregate(
// Pipeline
[
// Stage 1
{
$unwind: {
"path": "$transactions"
}
},
// Stage 2
{
$match: {
"transactions.amounts.balance": {
"$gt": 0.0
}
}
},
// Stage 3
{
$addFields: {
"openBalance": "$transactions.amounts.balance"
}
}

Answer 1

According to the documentation, $match will only use an index if it's used with no other preceeding stages.
If you place a $match at the very beginning of a pipeline, the query
can take advantage of indexes like any other db.collection.find() or
db.collection.findOne().
Since you unwind your documents first, $match won't use the index which you should see from the explain() plan, too.
Depending on your data, specifically, if you have lots of documents that do not contain a matching entry in the transactions.amounts.balance array, it can be helpful in terms of performance to simply duplicate the $match filter and put one to the very beginning of your pipeline in order to eliminate some of the documents. In the best case (again, this depends on your data), the resulting number of documents will be low enough for the second $match stage to not hurt performance any longer.