Evaluate moving from hash indexing to hash + number

Open
#403 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Refactor
Clarity
Needs clarification
Activity status
Stale
Tech stack
rust
Domain
databases, performance

Research direction

Start by locating the database definitions and access paths for the Headers, Bodies, Receipts, and TransactionLocations tables. Measure current hash-based lookups and identify iteration, reorg, or nearby-block workloads to compare against a (block_number, index) key. Done means a documented benchmark-based decision on whether the alternative is faster.

Written by the indexing model from the issue text.

Description

performance

Tables like Headers, Bodies, Receipts and TransactionLocations are indexed by block hash, as it's a unique identifier (block number isn't). However, it doesn't grant order. If we have (block_number, index) as the key, then we can have proximity in disk of blocks that are close together in time, potentially making the access to blocks that are near each other (for iterations, reorgs, etc) faster.

If db access performance becomes a blocker, this idea is worth exploring and measuring to check if it's effectively faster than normal hash indexing.

Dominant language
Rust
Stars
897
Forks
229
Avg merge
1d 5h
Merged PRs (30d)
44

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from lambdaclass/ethrex

All issues in lambdaclass/ethrex

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.