From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
---|---|
To: | pgsql-hackers mailing list <pgsql-hackers(at)postgresql(dot)org> |
Subject: | B-tree cache prefetches |
Date: | 2018-08-30 17:53:08 |
Message-ID: | 3B774C9E-01E8-46A7-9642-7830DC1108F1@yandex-team.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-08-30 17:56:52 | Re: pg_verify_checksums and -fno-strict-aliasing |
Previous Message | Peter Eisentraut | 2018-08-30 17:45:06 | Re: [HACKERS] Proposal to add work_mem option to postgres_fdw module |