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
