On Wed, Feb 9, 2011 at 2:51 PM, Markus Wanner <mar...@bluegap.ch> wrote: > On 02/09/2011 06:25 PM, Robert Haas wrote: >> On Wed, Feb 9, 2011 at 10:38 AM, Markus Wanner <mar...@bluegap.ch> wrote: >>> Thread based, dynamically allocatable and resizeable shared memory, as >>> most other projects and developers use, for example. > > I didn't mean to say we should switch to that model. It's just *the* > other model that works (whether or not it's better in general or for > Postgres is debatable). > >> Or less invasively, a small sysv shm to prevent the double-postmaster >> problem, and allocate the rest using POSIX shm. > > ..which allows ftruncate() to resize, right? That's the main benefit > over sysv shm which we currently use. > > ISTM that addresses the resizing-of-the-overall-shared-memory question, > but doesn't that require dynamic allocation or some other kind of > book-keeping? Or do you envision all subsystems to have to > re-initialize their new (grown or shrunken) chunk of it?
Basically, I'd be happy if all we got out of it was freedom from the oppressive system shared memory limits. On a modern system, it's hard to imagine that the default for shared_buffers should be less than 256MB, but that blows out the default POSIX shared memory allocation limits on every operating system I use, and some of those need a reboot to fix it. That's needlessly reducing performance and raising the barrier of entry for new users. I am waiting for the day when I have to explain to the guy with a terabyte of memory that the reason why his performance sucks so bad is because he's got a 16MB buffer cache. The percentage of memory we're allocating to shared_buffers should not need to be expressed in scientific notation. But once we get out from under that, I think there might well be some advantage to have certain subsystems allocate their own segments, and/or using ftruncate() for resizing. I don't have a concrete proposal in mind, though. It's very much non-trivial to resize shared_buffers, for example, even if you assume that the size of the shm can easily be changed. So I don't expect quick progress on this front; but it would be nice to have those options available. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
