Hi Andrey, hackers, Thanks for working on this patch. I'm really interested in this feature.
While reading through the code, one question that came up for me is how the responsibilities are split between nbtsearch.c and nbtcompare.c. Currently, nbtcompare.c seems to do quite a bit of engine work: it duplicates the binary search loop, slot probing, and rules like Heap TID tie-breaking and posting list traversal. I was wondering if we could follow the SortSupport (support proc 2) model here. That is, keep all search control flow in nbtsearch.c (the unified binary search loop, slot probing, interpolation, and TID tie-breaking), and keep nbtcompare.c strictly limited to primitive callbacks like direct tuple value extraction, scalar comparison, and the interpolation math. To see how this works in practice and check its extensibility, I refactored the patch along these lines and implemented int8 (bigint) support on top. With the search loop living in nbtsearch.c, adding int8 required zero changes to nbtsearch.c—just ~70 lines of callbacks in nbtcompare.c, rather than duplicating another search loop and TID tie-breaker. All regression tests and amcheck pass cleanly, and the refactored code shaves off about 90 lines of duplicate control flow without affecting search performance. Attached are the patches on top of your patch: - 0001: Refactor specialized search architecture to follow the SortSupport model. - 0002: Add specialized in-page search support for int8. Does this look like a sensible direction? Regards, Yao Feng
0002-Add-specialized-in-page-search-support-for-int8-bigi.patch
Description: Binary data
0001-Refactor-B-tree-specialized-search-architecture-to-f.patch
Description: Binary data
