RdLrT

@erikd - Looks like there is a check for Alonzo genesis hash too in dbsync for 10.1.x , but not in node , this means we end up maintaining different...

@Cmdv - it's still applicable, please re-open (I cannot re-open this from my end), please use github bot to manage staleness of issues like cardano-node repo, rather than the manual...

The reason to use bot is it gives control to any of the participants to comment and re-open as against relying on individuals who may miss a notification in a...

> That would be very useful indeed. I'd be happy to ask around, but prolly generate better reach if started via IO. I think at minimum , folks from below...

Those were just examples, there are a lot more that we would want to perhaps drill down and document , but my question was really if there is a preferred...

IMO - a breaking change has been long pending, would be nice to reduce some of the backlog on these (will also allow for more freedom with tx_out table updates)?

Seems to match here (since you've sent dump for epoch 57, assume you meant to check _active_ stake at epoch 57)? ``` sql select es.amount, encode(ph.hash_raw,'hex') as pool from epoch_stake...

> which version of node and dbsync you use ? For this instance, node 1.35.7 w/dbsync 13.1.0.0

> I haven't found a case where this query takes more than a few ms The query was shared just as an example - as actual ID might vary, the...

> However I'm not convinced queries will be faster. The performance would be much faster to query against address fields purely due to smaller index size lookup against tx_id (eliminated...