Conversation
|
|
||
| ## Use SQLite for storage | ||
|
|
||
| Usage would simplify the index on transaction issue and provide easier storage/lookup of ABI. Also solves the `fsync` question. |
There was a problem hiding this comment.
Does it solve it or just move it? I thought (by default) a transaction in sqlite implies an fsync. So if, for example, we do an sqlite transaction for each block, it'd be no different in fsync overhead as before.
There was a problem hiding this comment.
https://www.sqlite.org/pragma.html#pragma_synchronous
By default fsync is still used. So move is a better description. It does look like it can be smarter about the fsync than our current implementation. Although, our current implementation likely doesn't even need it.
There was a problem hiding this comment.
If we use "journal_mode=WAL" and "synchronous=normal" this should reduce fsync to only when the WAL is checkpointing.
There was a problem hiding this comment.
From our 11/8/2022 conversation on this topic:
- need to understand potential impacts on transaction processing time
- might explore alternative proposal adding filtering capabilities to SHiP.
4 participants
No description provided.