In our schema, for each transaction, we will maintain an index. The index is basically a mapping like txHash->(blockHash, blockIndex,index) which indicators the canonical block number this transaction is included. In another word, tx index is necessary for users to query a transaction/receipt based on the hash.
However there are 925M transactions in the mainnet. So the indexes can take more than 16GB space in the database. It's a lot.
So the idea is: for most users, they only care about the latest transactions they send. So we can drop off historical indexes to reduce disk usage.
So in this PR, we offer a new command flag called --history.transactions. User can specify how many indexes they want to maintain in db. For the older, we will GC them.
What's more, if users want to query some historical transactions when the indexes are GCed, he can change the history.transactions, so that in the background Geth will re-generate indexes. If history.transactions is 0, it means we generate all indexes.
In our schema, for each transaction, we will maintain an index. The index is basically a mapping like
txHash->(blockHash, blockIndex,index)which indicators the canonical block number this transaction is included. In another word, tx index is necessary for users to query a transaction/receipt based on the hash.However there are 925M transactions in the mainnet. So the indexes can take more than 16GB space in the database. It's a lot.
So the idea is: for most users, they only care about the latest transactions they send. So we can drop off historical indexes to reduce disk usage.
So in this PR, we offer a new command flag called
--history.transactions. User can specify how many indexes they want to maintain in db. For the older, we will GC them.What's more, if users want to query some historical transactions when the indexes are GCed, he can change the
history.transactions, so that in the background Geth will re-generate indexes. Ifhistory.transactionsis 0, it means we generate all indexes.