In an app usually only a fixed set of rows is returned when listing information. Additional records are fetched with the use of pagination or infinite scroll mechanism. Your Aggregates or SQL queries should always take into account the required number of records.
Not limiting the number of rows in a query results in unnecessary CPU use, IO consumptions on the database, and unwanted memory take on the Web Server - just to hold the result of the entire query. Imagine fetching 1K records in every call when all you need is the first 10 records.
Set the Max. Records property of the aggregate to the required usage.
If required, the <Aggregate>.Count contains the total count of records, without the Max. Records limitation.
With SQL queries:
To limit the number of rows, to the rows required in a SQL query, it isn't enough to set the Max. Records. This doesn't change the query itself to limit the number of rows (it limits the number of rows that are copied to the output record list, so there is still an unnecessary load on the database).
The solution is to control the number of rows inside the query:
With this change you no longer rely on the <Query>.Count property to get the correct count of rows complying with the original query conditions and joins.