Apr 26, 2023

Looking at the performance profile there are no obvious bottlenecks, which is good but also means no low hanging fruit. But the confirmation query must still read every input, which means it pages over every script and witness. It just doesn't page over them for the double spend query. That's important since that query is a multimap - it must exhaust the conflict list to find all possible matches (vs. just the first). But the confirmation queries only require sequence, point_fk, and parent_fk from the input table. I'm going to run some number to see what sizes would be if these were moved into the spend table and the input table was just the script and witness. This would require an extra link per input, to be stored in the spend table. Apart from the extra space, the downside is that it requires traversal of the spend table (direct, no search) in order to deserialize (read) the input/tx. Writing the data is really not a consequential difference, as both records need to be written and this just shifts from one to the other. Adding the additional link is immaterial at that point. So I'll measure the difference in total read against the difference in confirmation cost.