Adds optimization for related relations#4345
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.
|
montymxb
left a comment
montymxb
left a comment
There was a problem hiding this comment.
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
2 participants
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.