Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
util: compare raw and encoded keys without explicit decoding #5613
What have you changed?
This PR adds a function to check if the encoded and raw format refers to the same key.
The motivation is that we want to know if a lock is a primary lock. However, inside TiKV we use encoded keys while the stored primary key in the lock is in the raw format.
An alternatives are directly passing raw keys into the transaction layer. But this makes the transaction code uglier. The benchmark result below shows that for a typical key length (30 bytes), it takes just less than 10ns and in most cases, two different keys are different in their tails. So the performance impact is quite small.
What is the type of the changes?
How is the PR tested?
Does this PR affect documentation (docs) or should it be mentioned in the release notes?
Does this PR affect
My fault...Index keys don't become primary keys in pessimistic transactions. In optimistic transactions, index keys tend to become primary keys. I'll update the main thread.
Anyway, comparing from the end helps return early.
breeswish left a comment
Looks like this comparing implementation is even slower than simply decoding..
@sticnarf If there can be optimizations to do in this PR, then why not do it 🤪I guess the source of slowness is caused from too much abstractions instead of simple and raw array operation..
Note that in TiDB scenario, the key is very short and looks like the effectiveness of this PR can be very trivial.
My consideration is that this PR is going to be used in transactions to fix a bug in 3.0. Correctness is more important than effectiveness. (And comparing keys is far less costly compared to other operations like rocksdb seek, such optimizations don't improve the final performance much)
Later in master, we can further improve this. There will be more time to test before the next major release.
@sticnarf I don't think bug fix can be an excuse of writing inefficient code, especially considering that it is not that hard to be efficient, as well as this is not a bug that occurs in high priority clients (?).. If there are future plans to improve it, please open an new issue to track it and I can accept it.