Enable Vinyl cache in read view #3197
Labels
Milestone
Comments
locker
added a commit
that referenced
this issue
Mar 7, 2018
When scanning a secondary index, we actually track each tuple in the transaction manager twice - as a part of the interval read from the secondary index and as a point in the primary index when retrieving the full tuple. This bloats the read set - instead of storing just one interval for a range request, we also store each tuple returned by it, which may count to thousands. There's no point in this extra tracking, because whenever we change a tuple in the primary index, we also update it in all secondary indexes. So let's remove it to save us some memory and cpu cycles. This is an alternative fix for #2534 It should also mitigate #3197
locker
added a commit
that referenced
this issue
Mar 7, 2018
When scanning a secondary index, we actually track each tuple in the transaction manager twice - as a part of the interval read from the secondary index and as a point in the primary index when retrieving the full tuple. This bloats the read set - instead of storing just one interval for a range request, we also store each tuple returned by it, which may count to thousands. There's no point in this extra tracking, because whenever we change a tuple in the primary index, we also update it in all secondary indexes. So let's remove it to save us some memory and cpu cycles. This is an alternative fix for #2534 It should also mitigate #3197
locker
added
feature
locker
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If SELECT is called from read view, it doesn't populate the tuple cache, which may degrade performance of certain workloads. The issue was exacerbated by commit a31c2c1: now any SELECT called outside transaction is immediately forced into read view. We should store all newest tuples in cache, even if they are read from read view.
The text was updated successfully, but these errors were encountered: