Closed Bertg closed 9 months ago
Thank you for reporting this. I've looked into it and have some promising ideas. Stay tuned! :)
@Bertg, these performance issues have been resolved in 2.13.0
Thank you again for your contribution!
Wow! That was fast. Thanks!
Given I have the Following projection:
Then I see the following queries:
I identify these as follows:
It is my contention that this should be 1 query.
The first two queries should be combined. There is no reason that this should be done in 2 steps. Either the data can be fetched in a the first query or the queries should be combined in some sort of subquery.
The third (last) query is not needed. We know the limit is 100, and we received less than 100 records from the database. There is no need to go to the database again.
For a trivial example like this, this optimisation can be overkill, however, we have situations where we do projections for streams with hundreds of events. For a stream with 499 events the current implementation will do 11 queries, while an optimised one would only do 5. We use Sentry, and it detects this as an N+1 issue even.
We are using: