Mar 6, 2025

The other is the double spend query, which can run entirely concurrent across blocks (except for the rare encountered possible double spend). This is heavily store intensive (SSD/RAM) with very low CPU, which is why it runs so cheaply on the maxi. However completing it on the mini with nothing else running, sequentially by block, still maxes out SSD from the start. The reason it starts hard is the isolated run starts with tables fully populated, so all queries are max paging cost due to max conflicts. There are only three tables involved, the tx table (to get the hash, no search required), the point table (search for point matches), and the prevout table (which is read in sequential chunks by block, and contains all point indexes and parent tx ids). I can't imagine isolating resources any further for this query. So we'll see how long it takes in isolation. To get to its starting point on the mini requires 7.8 hours of download and validation, and 15 minutes of final confirmation. So it's starting from under 9 hours with a 15 hour Core baseline (11 on Linux). It looks possible that it could complete in a few hours, hard to say just yet.