Test Results for Commit c1b6346

Pull Request 5034: Results
Overall Status: ❌

Test Case Results

• ✅ 5n4pr_conf_10k_bintree: PASS (Duration: 115s)
• ✅ 5n4pr_conf_10k_change: PASS (Duration: 147s)
• ✅ 5n4pr_conf_change_dependant: PASS (Duration: 131s)
• ✅ 5n4pr_conf_change_independant: PASS (Duration: 129s)
• ✅ 5n4pr_conf_send_dependant: PASS (Duration: 130s)
• ✅ 5n4pr_conf_send_independant: PASS (Duration: 132s)
• ✅ 5n4pr_rocks_10k_bintree: PASS (Duration: 120s)
• ❌ 5n4pr_rocks_10k_change: FAIL (Duration: 142s)
• Log

Last updated: 2026-02-22 21:50:06 UTC

Can we apply the same approach to the account table? This would reduce the required storage in the pending, rep_weight, confirmation_height and extended ledger tables.

Can we apply the same approach to the account table? This would reduce the required storage in the pending, rep_weight, confirmation_height and extended ledger tables.

Maybe. But saving would be small and it also adds complexity because reading an account will then require two reads after the table is split. The value size should also be larger than the key size to get any savings.
Blocks table is the most obvious candidate for splitting. The value size is quite big, and the table itself has a lot of rows. The main trade-off is the double read pattern.