Mar 9, 2025

I just realized that the change the point table from "foreign point" - a 7 byte search key consisting of the point.hash primary key and the 3 byte point.index, resulted in a dramatic increase in hashmap collisions in the point table. The new point table search key is the full 32 byte sha256 hash and the 3 byte index. Since the original pk's were guaranteed to be unique, point table collisions were almost zero. Now they are more normally distributed. However, previously to obtain the fp, one had to search the input table for the sha256 hash. So it's ultimately better, but there is an aspect of it that I hadn't measured before. Combining the dual key previously was effective, because of the uniqueness of the pk. But combining the lower 8 bytes of the sha256 hash and the sequential point index for identical point.hashes was not previously measured, and it's very weak. Which means one of the issues has been long collision chains. I'll measure the actual rate with the old combiner and a more effective one. Since the combiner is only used in this one table, it can pay to have more computation and reduce the rate. Prob not huge, but definitely material.