From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Posix Shared Mem patch |
Date: | 2012-06-28 16:46:22 |
Message-ID: | CAMkU=1xcZ=162SWKHnA3_k+rRz9aqX2mD-sF8XaRMKVDK854fA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | Postg토토 사이트 추천SQL |
On Thu, Jun 28, 2012 at 8:26 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> 3. Consider adjusting the logic inside initdb. If this works
> everywhere, the code for determining how to set shared_buffers should
> become pretty much irrelevant. Even if it only works some places, we
> could add 64MB or 128MB or whatever to the list of values we probe, so
> that people won't get quite such a sucky configuration out of the box.
> Of course there's no number here that will be good for everyone.
This seems independent of the type of shared memory used and the
limits on it. If it tried and 64MB or 128MB and discovered that it
couldn't obtain that much shared memory, it automatically climbs down
to smaller values until it finds one that works. I think the
impediment to adopting larger defaults is not what happens if it can't
get that much shared memory, but rather what happens if the machine
doesn't have that much physical memory. The test server will still
start (and so there will be no climb-down), leaving a default which is
valid but just has horrid performance.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2012-06-28 16:53:13 | Re: Covering Indexes |
Previous Message | Tom Lane | 2012-06-28 16:32:43 | Re: Covering Indexes |