Matthias Benkort
Matthias Benkort
Additionally, it should be relatively easy to also add an optional `auxiliary_data_hash` to results if that's any useful. That would make it possible to know before querying whether an match's...
> @bakon11: This is THE fastest solution so far for me to use to obtain metadata and query with really nice speed Now you've triggered me. How fast 😏? I'd...
Let's make a separate ticket for the webhook because that's a whole different conversation. This is clearly not sustainable to do when synchronizimg from scratch. Or at least, the target...
I like the idea 🤨. I am curious to see how this affects the behavior of indexes. We can play around using `EXPLAIN QUERY PLAN` to see whether indexes are...
> Real query takes 5 ms. `SEARCH` is the keyword here. Regarding COLLATE, I _guess_ that if you create the virtual column as `COLLATE NOCASE` already, you may not need...
Looking into this ☝️, actually I kept the column as it was an simply added the virtual column with a `substr(address, -56)`; firstly because this avoir re-writing existing stuff and...
Sounds reasonable. I've seen myself needing this many times while benchmarking. I typically ended up with a custom version of kupo which would just `threadDelay 9999999999999` as soon as a...
I am assuming you're indexing _everything_ then? > doing so across the entire network would blow out memory / db Memory -> yes. DB -> no. Turning off `--prune-utxo` leads...
I originally wanted to include this as part of `v2.1.0` but I realized that I am missing some elements to really understand the use case and address the problem. I'll...