From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Ants Aasma <ants(at)cybertec(dot)at> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Scaling shared buffer eviction |
Date: | 2014-09-26 14:37:29 |
Message-ID: | 20140926143729.GB7550@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2014-09-26 17:01:52 +0300, Ants Aasma wrote:
> On Fri, Sep 26, 2014 at 3:26 PM, Andres Freund <andres(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-09-26 14:40:37 | Re: Replication identifiers, take 3 |
Previous Message | Andres Freund | 2014-09-26 14:32:01 | Re: Scaling shared buffer eviction |