Re: B-tree cache prefetches

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: B-tree cache prefetches
Дата
Msg-id CAH2-Wzm8YAsmzywAZjyifrHGtETq0nvJxP9zOsi3_KOwj0-+Yw@mail.gmail.com
обсуждение исходный текст
Ответ на B-tree cache prefetches  (Andrey Borodin <x4mmm@yandex-team.ru>)
Список pgsql-hackers
On Thu, Aug 30, 2018 at 10:53 AM, Andrey Borodin <x4mmm@yandex-team.ru> wrote:
> The idea is pretty simple - our search are cache erasing anyway, let's try to get at least some of it by prefetching
possibleways 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?

I once wrote a patch that used __builtin_prefetch() when fetching
tuples from a tuplesort. It worked reasonably well on my laptop, but
didn't seem to do much on another machine with another
microarchitecture (presumably the server with the alternative
microarchitecture had superior hardware prefetching). The conclusion
was that it wasn't really worth pursuing.

I'm not dismissing your idea. I'm just pointing out that the burden of
proving that explicit prefetching is a good idea is rather
significant. We especially want to avoid something that needs to be
reassessed every couple of years.

-- 
Peter Geoghegan


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: pg_verify_checksums and -fno-strict-aliasing
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Dimension limit in contrib/cube (dump/restore hazard?)