-
Notifications
You must be signed in to change notification settings - Fork 21.6k
core/rawdb, triedb/pathdb: re-structure the trienode history header #32907
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
core/rawdb, triedb/pathdb: re-structure the trienode history header #32907
Conversation
| keyLimit := len(keySection) | ||
| if i != len(owners)-1 { | ||
| keyLimit = int(keyOffsets[i+1]) | ||
| var keyStart, keyLimit uint32 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't expect the keyStarts and Limits to exceed 2 million, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes.
The dirty trienodes caused by a single block should be limited by the GasLimit.
For node key, it's the node path;
For node val, it's the mix of "full node value", and "partial node value diff";
Uint32 should be sufficient for them, unless we raise the gasLimit dramatically.
MariusVanDerWijden
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
|
Let's merge it, making it easier for rebase work. |
…thereum#32907) In this PR, several changes have been made: (a) restructure the trienode history header section Previously, the offsets of the key and value sections were recorded before encoding data into these sections. As a result, these offsets referred to the start position of each chunk rather than the end position. This caused an issue where the end position of the last chunk was unknown, making it incompatible with the freezer partial-read APIs. With this update, all offsets now refer to the end position, and the start position of the first chunk is always 0. (b) Enable partial freezer read for trienode data retrieval The partial freezer read feature is now utilized in trienode data retrieval, improving efficiency.
…thereum#32907) In this PR, several changes have been made: (a) restructure the trienode history header section Previously, the offsets of the key and value sections were recorded before encoding data into these sections. As a result, these offsets referred to the start position of each chunk rather than the end position. This caused an issue where the end position of the last chunk was unknown, making it incompatible with the freezer partial-read APIs. With this update, all offsets now refer to the end position, and the start position of the first chunk is always 0. (b) Enable partial freezer read for trienode data retrieval The partial freezer read feature is now utilized in trienode data retrieval, improving efficiency.
In this PR, several changes have been made:
(a) restructure the trienode history header section
Previously, the offsets of the key and value sections were recorded before encoding
data into these sections. As a result, these offsets referred to the start position of
each chunk rather than the end position.
This caused an issue where the end position of the last chunk was unknown, making
it incompatible with the freezer partial-read APIs. With this update, all offsets now
refer to the end position, and the start position of the first chunk is always 0.
(b) Enable partial freezer read for trienode data retrieval
The partial freezer read feature is now utilized in trienode data retrieval, improving
efficiency.