| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Merlin Moncure <mmoncure(at)gmail(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:47:52 |
| Message-ID: | 20140925144752.GG9633@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2014-09-25 09:34:57 -0500, Merlin Moncure wrote:
> 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.
One interesting part of this is making sure it doesn't regress
older/smaller machines. So at least that side you could check...
> what's wrong with trying it out?
If somebody is willing to do it: nothing. I'd just much rather do the,
by now proven, simple change before starting with more complex
solutions.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2014-09-25 15:03:31 | Re: proposal: rounding up time value less than its unit. |
| Previous Message | Robert Haas | 2014-09-25 14:42:29 | Re: Scaling shared buffer eviction |