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
We should be dropping as much information as we can when ingesting chain data.
The first example I have is the Proof fields in jsonb in the parsed_messages table, which for a full chain seems to amount to a lot of data. The messages table also stores the binary parameters (which is redundant if it is also stored as parsed data?).
There are binary columns like ticket and election_proof in the block_headers table. We are also storing the drand binary randomness value.
Acceptance Criteria
Remove ticket and election_proof from block_headers
Remove params from messages
Remove drand_entries entire
Remove return in receipts
The text was updated successfully, but these errors were encountered:
* chore: remove ingestion for binary and unused data
- Remove the following tables:
- public.drand_entries
- Remove the Following columns:
- public.block_headers ticket
- public.block_headers election_proof
- public.messages params
- public.receipts return
closes#204
* fix: Reorder migration to merge to master
Co-authored-by: Mike Greenberg <[email protected]>
We should be dropping as much information as we can when ingesting chain data.
The first example I have is the Proof fields in jsonb in the parsed_messages table, which for a full chain seems to amount to a lot of data. The messages table also stores the binary parameters (which is redundant if it is also stored as parsed data?).
There are binary columns like
ticket
andelection_proof
in the block_headers table. We are also storing the drand binary randomness value.Acceptance Criteria
ticket
andelection_proof
from block_headersparams
from messagesdrand_entries
entirereturn
in receiptsThe text was updated successfully, but these errors were encountered: