After years of development, the TiKV coprocessor has become more and more powerful, while inevitably, the codebase has become even bigger.
In the past year, we have been working on various parts of the coprocessor framework, including improving the memory layout, adding new evaluation types, and adding raw coprocessor. From my perspective, I believe there are a lot of things to do:
- More efficient data encoding. Directly copy encoded chunk format data from memory to protobuf fields. There were some attempts, but failed due to some unknown bugs.
- More efficient memory layout. When refactoring the framework to enable the enum pushdown earlier this year, we found ourselves in a dilemma: to use a less efficient memory layout for fewer engineering efforts, or to use a very compact memory layout that requires a large refactor. After some discussions we chose the former way. There is room for improvement.
- More use cases. For raw coprocessor (or so-called coprocessor v2 or coprocessor plugins), there is still no real-world usage of the new framework. We may add some example plugins.
- Easier to maintain. There are a lot of unsafe transmute of lifetimes in current query executors. GAT (generic associated types) could probably save us from such a mess. We may look into possibilities to use GAT in our codebase later when this language feature becomes stable.
What’s your opinion on the future of the TiKV coprocessor?