Hi hackers! I've been at the database conference and here everyone is talking about cache prefetches.
I've tried simple hack diff --git a/src/backend/access/nbtree/nbtsearch.c b/src/backend/access/nbtree/nbtsearch.c index d3700bd082..ffddf553aa 100644 --- a/src/backend/access/nbtree/nbtsearch.c +++ b/src/backend/access/nbtree/nbtsearch.c @@ -401,6 +401,13 @@ _bt_binsrch(Relation rel, /* We have low <= mid < high, so mid points at a real slot */ + OffsetNumber x = mid + 1 + ((high - mid + 1) / 2); + if (x < high) + __builtin_prefetch (PageGetItem(page, PageGetItemId(page, x)), 0, 2); + x = low + ((mid - low) / 2); + if (x > low) + __builtin_prefetch (PageGetItem(page, PageGetItemId(page, x)), 0, 2); + result = _bt_compare(rel, keysz, scankey, page, mid); if (result >= cmpval) The idea is pretty simple - our search are cache erasing anyway, let's try to get at least some of it by prefetching possible ways of binary search. And it seems to me that on a simple query > insert into x select (random()*1000000)::int from generate_series(1,1e7); it brings something like 2-4% of performance improvement on my laptop. Is there a reason why we do not use __builtin_prefetch? Have anyone tried to use cache prefetching? Best regards, Andrey Borodin.