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.

Reply via email to