-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
Adds optimization for related relations #4345
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Looks to be something up with the test case on postgres, maybe it doesn't know what to do with some of |
Codecov Report
@@ Coverage Diff @@
## master #4345 +/- ##
==========================================
+ Coverage 92.64% 92.64% +<.01%
==========================================
Files 119 119
Lines 8426 8435 +9
==========================================
+ Hits 7806 7815 +9
Misses 620 620
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome 👍 ! Also (if you've tested against this) how much of a benefit are you seeing from this change?
Instead of pulling data from the full join (possibly 1000’s of objects) this will only pull a few. In only works you’re sorting on createdAt, as it’s represented on the mongoDB_id. |
I got that, I just wanted to know if there was an actual benchmark of sorts that you might have had for a particular case. But that's just for my personal interest. |
Beyond that we're good though! |
We're seeing very large data in some relations that are actually sorted this way, so that really helps if returning data faster :) |
* Adds optimization for related relations * Makes MongoStorageAdapter only able to sort on Join tables
So we ran a bit the aggregation optimization in prod and this was not satisfactory, not yielding enough benefits in terms of performance.
Went back to the drawing board and came up with this idea of leveraging the _id managed by mongoDB (which is ascending at creation time) to reduce the amount of keys pulled from the join table.
If you're sorting by createdAt ascending or descending, you'll benefit this optimization, otherwise, that will pretty much be the same.