Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 90FFE9F9C79 for ; Wed, 5 Sep 2007 12:57:03 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 54586-05-2 for ; Wed, 5 Sep 2007 12:57:00 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5 Received: from tomts10-srv.bellnexxia.net (tomts10.bellnexxia.net [209.226.175.54]) by postgresql.org (Postfix) with ESMTP id CA2D89FA15D for ; Wed, 5 Sep 2007 12:56:54 -0300 (ADT) Received: from serenity ([70.52.67.95]) by tomts10-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20070905155653.EHFW9197.tomts10-srv.bellnexxia.net@serenity>; Wed, 5 Sep 2007 11:56:53 -0400 From: "Carlo Stonebanks" To: "'Alvaro Herrera'" Cc: References: <20070904230639.GA23731@alvh.no-ip.org> In-Reply-To: <20070904230639.GA23731@alvh.no-ip.org> Subject: Re: Performance on 8CPU's and 32GB of RAM Date: Wed, 5 Sep 2007 11:57:19 -0400 Message-ID: <4F731254987542AF807CA3EDF411D12B@serenity> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16480 Thread-Index: AcfvSE17Kr29VyQpQjq/9b1iHnJgNAAAJhzg X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.001 tagged_above=0 required=5 tests=BAYES_50=0.001 X-Spam-Level: X-Archive-Number: 200709/53 X-Sequence-Number: 26598 >> Large shared_buffers and Windows do not mix. Perhaps you should leave the shmem config low, so that the kernel can cache the file pages. << Is there a problem BESIDES the one that used to cause windows to fail to allocate memory in blocks larger than 1.5GB? The symptom of this problem was that postgresql would just refuse to restart. Microsoft released a patch for this problem and we can now start postgresql with larger shared buffers. If this is indeed the problem that you refer to - and it has indeed been solved by Microsoft - is there a down side to this? >> It sounds like you will need a huge lot of vacuuming effort to keep up. Maybe you should lower autovac scale factors so that your tables are visited more frequently. A vacuum_delay of 40 sounds like too much though. << Does autovacuum not impede performance while it is vacuuming a table?