On 2014-09-26 17:01:52 +0300, Ants Aasma wrote: > On Fri, Sep 26, 2014 at 3:26 PM, Andres Freund <and...@2ndquadrant.com> wrote: > > 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. > > I'm not arguing against a more efficient hash table, but one simple > win would be to have a buffer tag specific comparison function. I mean > something like the attached patch. This way we avoid the loop counter > overhead, can check the blocknum first and possibly have better branch > prediction.
Heh. Yea. As I wrote to Heikki, 64bit compares were the thing showing most benefits - at least with my own hashtable implementation. > Do you have a workload where I could test if this helps alleviate the > comparison overhead? Fully cached readonly pgbench workloads with -M prepared already show it. But it gets more pronounced for workload that access buffers at a higher frequency. At two customers I've seen this really badly in the profile because they have OLTP statements that some index nested loops. Often looking the same buffer up *over and over*. There often isn't a better plan (with current pg join support at least) for joining a somewhat small number of rows out of a large table to small/mid sized table. 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
