Received: from localhost (unknown [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id 6AB0F9FA635 for ; Thu, 6 Sep 2007 17:40:45 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 96754-08 for ; Thu, 6 Sep 2007 17:39:57 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from pih-relay04.plus.net (pih-relay04.plus.net [212.159.14.131]) by postgresql.org (Postfix) with ESMTP id DC0459FA651 for ; Thu, 6 Sep 2007 17:39:57 -0300 (ADT) Received: from [80.229.150.39] (helo=mansionfamily.plus.com) by pih-relay04.plus.net with esmtp (Exim) id 1ITO84-00033H-Uf for pgsql-performance@postgresql.org; Thu, 06 Sep 2007 21:39:09 +0100 Received: from [192.168.0.87] ([192.168.0.87]:1674) by mansionfamily.plus.com with [XMail 1.22 ESMTP Server] id for from ; Thu, 6 Sep 2007 21:42:07 +0100 Message-ID: <46E0657E.30401@mansionfamily.plus.com> Date: Thu, 06 Sep 2007 21:39:26 +0100 From: James Mansion User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Scott Marlowe CC: Carlo Stonebanks , Alvaro Herrera , pgsql-performance@postgresql.org Subject: Re: Performance on 8CPU's and 32GB of RAM References: <20070904230639.GA23731@alvh.no-ip.org> <3DCCF196F82444998B33F40C97B71CA4@serenity> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200709/100 X-Sequence-Number: 26645 Scott Marlowe wrote: > Where unixes generally outperform windows is in starting up new > backends, better file systems, and handling very large shared_buffer > settings. > Why do you think that UNIX systems are better at handling large shared buffers than Wndows? 32 bit Windows systems can suffer from fragmented address space, to be sure, but if the performance of the operating-system supplied mutex or semaphore isn't good enough, you can just use the raw atomic ops. If what you mean is that pg has a design that's heavily oriented towards things that tend to be cheap on POSIX and doesn't use the core Win32 features effectively, then let's track that as an optimisation opportunity for the Win32 port.