Feb 9, 2025

I completed the above test runs on maxi and mini, and there is no consequential change, though the code is simpler. I was also able to remove the search (hashmap) index from the point table, which saved 4 bytes per row plus the header, or 12GiB. I've concluded that on the mini nothing will get faster as long as the same amount of confirmation paging is required. Based on a lot of inspection I can see that the is-spent exhaustive search over the spend table is where the real cost is. The only way I can see to reduce paging from this is to remove all data not necessary to the search. IOW make it a simple index that points to the remaining data. There is already structure for this, as the spend points to the point table, where the prevout hash is stored. So I can move the parent and input pointers, and the input.sequence value (12 bytes) to the point table. This moves 29GiB (40%) out of the spend table. This will definitely reduce spend query paging, and given that the point hash is already necessary for reading and writing a tx, moving the sequence there isn't an extra cost for download/validate. It does increase the point table, which increases paging there, but we don't do that for spend hashmap conflicts, so should save a lot of paging overall. Relatively simple change as well. On the maxi I believe that implementing the custom std lib concurrency replacement (required for gcc/clang anyway) with a thread pool may significantly improve performance, because the main limitation there (about 75% cost) is lock contention.