Larger Hash index Splitting

[benjaminwinger]

It might make sense to try splitting a full page of slots (4096/256 = 16) each time we split. That would usually not increase the number of pages touched, and should not add significant overhead, but could help somewhat in reducing overall i/o (though it doesn't reduce the amount of wal page pins/unpins, since those are being done individually, but maybe we could do a single read + single write for the split instead).

E.g. for individual CREATE statements: For 8-byte keys (14 entries per slot), once we reach 66% of capacity we split about once every 9 insertions, and each split will write to two pages (in addition to the page containing the slot which holds the new key). Since splitting happens to slots incrementally, this means that 16 splits in a row occur within the same two pages (ignoring overflow slots, which reduce the benefits since they aren't grouped together on disk).

It's probably not huge though in terms of overall writes. 2 extra pages written every 9 CREATEs means 20 instead of 18 pages written in total (assuming no rehashing occurs each insert should modify just two pages, the header, and the slot being inserted into; more for long strings). This would make that be two extra pages every ~149 inserts instead. I suspect that in terms of real-world performance, bypassing the disk array when doing the split and updating the slots just once might have more of a performance impact (though we can do that regardless).