Re: Experimenting with hash join prefetch - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Experimenting with hash join prefetch
Date
Msg-id CA+Tgmoa29WzpSOyXwx97bshSPVAr5t1DyAwTw9ZnHaA3PYNfSQ@mail.gmail.com
Whole thread Raw
In response to Re: Experimenting with hash join prefetch  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Experimenting with hash join prefetch
List 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 by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pg_rewind vs superuser
Next
From: Robert Haas
Date:
Subject: Re: block-level incremental backup