Skip site navigation (1) Skip section navigation (2)

Re: Posix Shared Mem patch

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 (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

pgsql-hackers by date

Next:From: Jeff JanesDate: 2012-06-28 16:53:13
Subject: Re: Covering Indexes
Previous:From: Tom LaneDate: 2012-06-28 16:32:43
Subject: Re: Covering Indexes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group