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. Besides making the hashtable more efficent, a smaller key (say, 4 byte relfilenode, 4 byte blocknumber) would also make using a radix tree or similar more realistic. I've prototyped that once and it has nice properties, but the tree is too deep. Obviousy it'd also help making buffer descriptors smaller, which is also good from a cache efficiency perspective... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
