It looks like indexes currently chosen by the planner don't quite fit your query.
I would create the following index (if it's possible to update schema):
ON "uniswap_v2.Pair_evt_Mint" (evt_tx_hash, evt_block_time)
Same for the second table, looks like
ON "ethereum.transactions" (hash, block_time)
is a better fit for your query. In fact, I do not think `transactions_block_number_time` index is used frequently, 'cos second column of the index is a partitioning key.
Currently planner wants to go via indexes 'cos you've made random access really cheap compared to sequential one (and your findings shows this).
Perhaps on a NVMe disks this could work, but in your case you need to find the real bottleneck (therefore I asked for buffers).
I would set `random_page_cost` to a 2.5 at least with your numbers. Also, I would check DB and indexes for bloat (just a guess now, 'cos your plans miss buffers figures).
--
