Closed raphjaph closed 1 month ago
I think only if it improves performance / reduces the size of the database.
I looked at this briefly when I was doing the unified table work! It's a plausible idea, although there are two issues:
Runes are currently a very small fraction of the database size (about 0.25 GB of keys and values) and indexing time, so the gains would be minimal right now. This will likely change over the next couple of years.
Runes aren't processed in the same order as inscriptions: inscriptions handle the coinbase transaction after the rest of the block, whereas runes handle it at the beginning. This wasn't a problem for sats and addresses, since they're order-independent; I just switched them to follow the same order as inscriptions so they could all be processed together. But runes and inscriptions both depend on ordering, so we'd have to deal with the mismatch somehow.
So my feeling is this probably isn't worth the code churn right now, although it might be worth looking at again in a few years. In the meantime, though, it would be nice to keep the ordering issue in mind when adding new features -- any new features that depend on processing order will make it harder to unify those tables later.
Seems reasonable to me. Let's revisit this when it becomes more of a win. Hopefully runes will just completely die off so we never have to deal with it 😂
We have these two tables. Would it make sense to put the rune balances into the
UtxoEntry
/ParseUtxoEntry
as well and combine these two tables? @partialord @casey