On 09/26/2014 03:26 PM, Andres Freund wrote:
On 2014-09-26 15:04:54 +0300, Heikki Linnakangas wrote:
On 09/25/2014 05:40 PM, Andres Freund wrote:
There's two reasons for that: a) dynahash just isn't very good and it
does a lot of things that will never be necessary for these hashes. b)
the key into the hash table is*far* too wide. A significant portion of
the time is spent comparing buffer/lock tags.
Hmm. Is it the comparing, or calculating the hash?
Neither, really. The hash calculation is visible in the profile, but not
that pronounced yet. The primary thing noticeable in profiles (besides
cache efficiency) is the comparison of the full tag after locating a
possible match in a bucket. 20 byte memcmp's aren't free.
Hmm. We could provide a custom compare function instead of relying on
memcmp. We can do somewhat better than generic memcmo when we know that
the BufferTag is MAXALIGNed (is it? at least it's 4 bytes aligned), and
it's always exactly 20 bytes. I wonder if you're actually just seeing a
cache miss showing up in the profile, though.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
