Index block information

[joshstevens19]

it be nice to be able to index the block information once and then join from the block number to those tables meaning you do not repeat block hash and timestamp all the time. This task is to write the block information in the database as well and remove the repeating fields it does when it indexes an event each time, this will save space in the database.

[MattKetmo]

Hello. Talking about saving space in the database, what about using bytea instead of char for hash & address columns?
(this has also the advantage not to worry about case sensitivity)

[joshstevens19]

The main reason char(42) works quite nice as the db protects against bad mistakes from the code say the address got messed up somehow, it would throw on the DB level and not just let it happen, which can make you see some of these issues before they become impossible to find - sometimes they may have more benefit then space.. opening to talk about bytea if we feel the size benefit is dramatically better cc @MattKetmo

[MattKetmo]

@joshstevens19 what kind of protection does it really provide?
I see it can protect against a too long string, but it won't protect against a a smaller string or same size but messed chars (like wrong case ;)).

bytea doesn't have a fixed length but it's still very easy to run a query to check the correct length of data.

I'm curious what you have in mind in term of protection.

[joshstevens19]

you are probably right tbh char(42) it just pad it if its to short or shorten it its to long which has the same kind of issue (does not protect anymore), so yeah bytea sounds like it has the same benefit but smaller size so I'm up to change it feel free to create an issue for it and il look at it thanks for the suggestion