3 ms·
This project looks really exciting! I'm working on mvsqlite [1], a distributed SQLite based on FoundationDB. When doing the VFS integration I have always wante
by losfair 4y ago
This project looks really exciting!
I'm working on mvsqlite [1], a distributed SQLite based on FoundationDB. When doing the VFS integration I have always wanted to patch SQLite itself, but didn't because of uncertainty around correctness of the patched version...
A few features on my wishlist:
1. Asynchronous I/O. mvsqlite is currently doing its own prefetch prediction that is not very accurate. I assume higher layers in SQLite have more information that can help with better prediction.
2. Custom page allocator. SQLite internally uses a linked list to manage database pages - this causes contention on any two transactions that both allocate or free pages.
3. Random ROWID, without the `max(int64)` row trick. Sequentially increasing ROWIDs is a primary source of contention, and causes significant INSERT slowdown in my benchmark [2].
[1] https://github.com/losfair/mvsqlite https://github.com/losfair/mvsqlite
[2] https://univalence.me/posts/mvsqlite-bench-20220930 https://univalence.me/posts/mvsqlite-bench-20220930
- chasil 4y agoMy guess is that, with the oncoming changes for concurrent writers, these will be implemented in time. Still, Rome was not built in a day, and functionality must take a backseat to reliability and legacy compatibility. https://www.sqlite.org/cgi/src/doc/begin-concurrent/doc/begin_concurrent.md https://www.sqlite.org/cgi/src/doc/begin-concurrent/doc/begi...