Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 944C164FE8F for ; Wed, 15 Oct 2008 13:13:43 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 80522-06 for ; Wed, 15 Oct 2008 13:13:40 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id BDEF164FCFB for ; Wed, 15 Oct 2008 13:13:40 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m9FGD4X5022703; Wed, 15 Oct 2008 12:13:04 -0400 (EDT) To: Greg Smith cc: Gregory Stark , Kevin Murphy , pgsql-general@postgresql.org Subject: Re: Drupal and PostgreSQL - performance issues? In-reply-to: References: <2434A118-CEFA-43A9-BA88-006EC1F80326@hoegh.org> <200810122214.53558.uwe@oss4u.com> <20081013090228.248a665f@dawn.webthatworks.it> <20081014114011.0ebe495a@dawn.webthatworks.it> <3250B5B6-B507-4E79-BAF0-E98B73E9FED9@hoegh.org> <48F4B3C2.1050805@genome.chop.edu> <87od1mbpsv.fsf@oxford.xeocode.com> Comments: In-reply-to Greg Smith message dated "Wed, 15 Oct 2008 02:20:13 -0400" Date: Wed, 15 Oct 2008 12:13:03 -0400 Message-ID: <22702.1224087183@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200810/613 X-Sequence-Number: 138862 Greg Smith writes: > If there were ever any Linux distributions that increased this value from > the tiny default, you might have a defensible position here (maybe > Oracle's RHEL fork does, they might do something here). I've certainly > never seen anything besides Solaris ship with a sensible SHMMAX setting > for database use on 2008 hardware out of the box. It's really quite odd, > but as numerous probes in this area (from the above in 2000 to Peter's > recent Linux bugzilla jaunt) show the resistance to making the OS default > to any higher is considerable. I think the subtext there is that the Linux kernel hackers hate the SysV IPC APIs and wish they'd go away. They are presently constrained from removing 'em by their desire for POSIX compliance, but you won't get them to make any changes that might result in those APIs becoming more widely used :-( Mind you, I find the SysV APIs uselessly baroque too, but there is one feature that we have to have that is not in mmap(): the ability to detect other processes attached to a shmem block. regards, tom lane