| From: | Ants Aasma <ants(at)cybertec(dot)at> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| 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:01:52 |
| Message-ID: | CA+CSw_spxTeW1tm6e8FuhH1phKsfjCcJJdBue8dOpUjtqNvKtw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
Do you have a workload where I could test if this helps alleviate the
comparison overhead?
Regards,
Ants Aasma
--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de
| Attachment | Content-Type | Size |
|---|---|---|
| optimized-buffer-tag-cmp.patch | text/x-patch | 1.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2014-09-26 14:20:15 | WITH CHECK and Column-Level Privileges |
| Previous Message | Robert Haas | 2014-09-26 13:59:41 | Re: Scaling shared buffer eviction |