Re: Experimenting with hash join prefetch

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Experimenting with hash join prefetch
Дата
Msg-id CA+Tgmoa29WzpSOyXwx97bshSPVAr5t1DyAwTw9ZnHaA3PYNfSQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Experimenting with hash join prefetch  (Thomas Munro <thomas.munro@gmail.com>)
Ответы Re: Experimenting with hash join prefetch  (Thomas Munro <thomas.munro@gmail.com>)
Список pgsql-hackers
On Wed, Apr 10, 2019 at 2:10 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> Here is an example of times for a trivial join on my laptop.  Note
> that this is prefetching only the probing phase, not while building
> which should also be possible.  I didn't get around to trying deeper
> prefetch pipelines as discussed earlier, but those seemed to produce
> diminishing returns with hardcoded tests like in the earlier message.

It would be interesting to see how this does with moderately-long text
keys, say 32 or 64 byte strings, and with actually-long text keys, say
several kB, and then with gigantic text keys, say several MB.  At some
point the key probably gets large enough that computing the hash value
for the next key evicts the current key from the relevant CPU cache,
and if I had to guess, at that point prefetching will become a loser.
But I don't know where that point is.  If it turns out for example
that this technique is a winner for pass-by-value datatypes and a
loser for pass-by-reference datatypes, or that it's a winner always,
or some sort of simple rule like that, awesome!  But if it turns out
that there's no simple rule that we can use to know whether it wins or
loses, then that might make things a little tricky.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: pg_rewind vs superuser
Следующее
От: Robert Haas
Дата:
Сообщение: Re: block-level incremental backup