Thanks for opening this issue!

• 🚀 You can help us to fix this issue faster by opening a pull request with a failing test. See our Contribution Guide for how to make a pull request, or read our New Contributor's Guide if this is your first time contributing.

I think that's how it's supposed to work, count the total of the query, to you know how many pages with skip/limit you can navigate.
In your case, you already know how much would be the count, the same as the limit you asked for.. and if is less, the current count would bring the correct count.

I think that's how it's supposed to work, count the total of the query, to you know how many pages with skip/limit you can navigate. In your case, you already know how much would be the count, the same as the limit you asked for.. and if is less, the current count would bring the correct count.

It can still count 100k+ rows for my use case (counting a user's unread messages) when I try to limit it to 100, it's a bit unnecessary.

The MongoDB count operation supports the limit parameter, see docs. It may be more efficient than a db.collection.find(query).limit(number).count();. So I assume supporting the limit param has a use case.

but if you put a limit of 100, what do you expect to be the count result?

A value between 0 and 100 :)

I see, but as I said before, the count is to know how many times you can page it.
For example: 140 articles with a limit of 10, 14 pages.
the way you want, you don't need to count
Just get the return array and ask for the length.

I agree with @matheusfrozzi here. Altering the current behaviour of the count() method makes no sense.
Just get the length of the query's returned array for your use case.
If you want to change anything regarding that anyway, I think it's better to add a new method limitCount() for example or add an optional property to the count method: count({ withinLimit: true }).

This is primarily a syntax question. Whether there are use cases for it is a different topic. I believe the expected behavior of Parse.Query.limit(n).count() would be that it respects limit(n). Ignoring limit(n) would be syntactically counterintuitive.

There is of course a practical aspect to it. If you want to know whether a collection of N documents contains less than or equal to n documents matching a filter, then a database engine optimization may stop the query cursor once it has found n documents, instead of going through all N documents.

In fact, MongoDB hints towards that:

cursor.limit says:

Use limit() to maximize performance and prevent MongoDB from returning more results than required for processing.

cursor.count also provides a specific example:

db.orders.find( { ord_dt: { $gt: new Date('01/01/2012') } } ).limit(5).count(true)

Since MongoDB explicitly supports the optional limit parameter for count operations, we can assume that the engine does optimize.