Since all writes are already serialized via the oracle and the task channel, there's actually no need to hold the index write lock while updating it because there can be no other concurrent transactions updating the index at the same time.
It's sufficient to clone it using the cheaper read lock, make all the modifications, and then update it as a whole at once. This is sorta RCU thanks to the copy-on-write vart tree. This should help parallel readers to experience less contention when starting transactions.
As a follow-up, we could probably take it even further by getting rid of the RWLock completely and use atomic pointer swap instead, for example the arc-swap crate.
Since all writes are already serialized via the oracle and the task channel, there's actually no need to hold the index write lock while updating it because there can be no other concurrent transactions updating the index at the same time. It's sufficient to clone it using the cheaper read lock, make all the modifications, and then update it as a whole at once. This is sorta RCU thanks to the copy-on-write vart tree. This should help parallel readers to experience less contention when starting transactions.
As a follow-up, we could probably take it even further by getting rid of the RWLock completely and use atomic pointer swap instead, for example the
arc-swapcrate.Tested with SurrealDB.