I'll admit to not reading your code. It's hard to keep up with all the different databases launched in the last decade.
I have doubts that a global readwrite lock around a hashtable makes for a good general purpose storage system.
I have doubts that a global readwrite lock around a hashtable makes for a good general purpose storage system.
Calling it a "hashtable" is something that only someone who hasn't built a DB engine would do. It's incredibly naive. It discounts the complexity of execution, atomicity, durability, constraint validation, migrations, query planning, incremental query evaluation, down to zero. It really makes it sound like he has absolutely no idea what he's talking about.
Besides, it's a btree (heh).
> We spent a lot of money finding out that a lock is more performant.
I want to hear about that journey.
> Besides, it's a btree.
I guess it's not a hash table, but I think the point of Vincent's post is still worth exploring. You and he both say that essentially a key/value store is mutexed, and the user's code runs inside that mutex. That is fascinating. Why would that be better? Clearly it is, or you wouldn't have spent the money. What controls did you put in place to ensure user code didn't blow up the performance, or did you even feel the need for such controls? Is WASM VM execution fast enough for this? Is there even a market for that? Who pays to put their code inside that mutex and why? I want to know more.
The TL;DR is that because you're not holding locks across the network (as is the case in Postgres), your server code can complete transactions in single digit microseconds, rather than milliseconds. And the practical effect is you can do many more transactions per second as a result.
(I mention this mainly as a keyword that people can look up for more information)