According to firebase documentation, when you use the count aggregation query, you are charged according to the number of index reads that are done. However this is contradicted by the statement from Frank van Puffelen here new count() aggregation function performance who said you are charged according to the value of the count returned in response to the query. If you do a count query that involves two "where" clauses e.g.
.where("country", isEqualTo: "United States")
.where("age", isGreaterThan: "100")
where the first where clause finds 100,000 matches and the second where clause reduces the match count to 900, the count returned is 900. According to Frank you get charged for one read (900 divided by 1000, plus one). However, since 100,000 indexes were read, I'm wondering if you get charged for 100,000 divided by 1000 reads i.e. you get charged for 100 reads.
Furthermore, the firebase documentation here https://cloud.google.com/firestore/pricing#index-reads says this
Queries that have up to one range field are not charged for index entries read.
so for the example I gave above, this means you are not charged for any index reads at all. So which is correct for the example I gave
Firestore uses a dedicated index for the query you specify. So your two conditions identify a single slice of data in the composite index that is used.
If the count query with your condition returns a count of 900, it scanned 900 index items for that count and you get charged 1 document read for that.