You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 15, 2023. It is now read-only.
With #760 The blocks are indexed by hash in the database which has a negative impact on performance. Keeping blocks close to each other in the DB allows for better utilisation of the database cache and disk IO when querying ranges of blocks. We need to bring back the block-by-number DB scheme. The problem is that two blocks that are not yet finalized can share the same number. I can think of two ways to get around that:
Store current unfinalized best blocks by number. Any extra blocks are stored with additional suffix or by hash. In case of chain reorg the blocks are re-inserted with new keys. This implementation looks more preferable unless chain reorgs are too frequent.
Keep the blocks in the journal similar to state changes in state-db. On finalization the block is moved from the journal to the main storage with a proper key.
With #760 The blocks are indexed by hash in the database which has a negative impact on performance. Keeping blocks close to each other in the DB allows for better utilisation of the database cache and disk IO when querying ranges of blocks. We need to bring back the block-by-number DB scheme. The problem is that two blocks that are not yet finalized can share the same number. I can think of two ways to get around that:
Store current unfinalized best blocks by number. Any extra blocks are stored with additional suffix or by hash. In case of chain reorg the blocks are re-inserted with new keys. This implementation looks more preferable unless chain reorgs are too frequent.
Keep the blocks in the journal similar to state changes in
state-db. On finalization the block is moved from the journal to the main storage with a proper key.