| From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Robert Haas <robertmhaas(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-25 14:34:57 |
| Message-ID: | CAHyXU0y6NKw54hm23MgpsMvCoQHcjpoPwwO8LPQW05mtP-s1Yw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Sep 25, 2014 at 9:14 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> Why stop at 128 mapping locks? Theoretical downsides to having more
>> mapping locks have been mentioned a few times but has this ever been
>> measured? I'm starting to wonder if the # mapping locks should be
>> dependent on some other value, perhaps the # of shared bufffers...
>
> Wrong way round. You need to prove the upside of increasing it further,
> not the contrary. The primary downside is cache hit ratio and displacing
> other cache entries...
I can't do that because I don't have the hardware. I wasn't
suggesting to just set it but to measure the affects of setting it.
But the benefits from going from 16 to 128 are pretty significant at
least on this hardware; I'm curious how much further it can be
pushed...what's wrong with trying it out?
merlin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2014-09-25 14:35:23 | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |
| Previous Message | Simon Riggs | 2014-09-25 14:31:00 | Re: Index scan optimization |