X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id F3A2E528AE for ; Mon, 30 May 2005 13:54:58 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 65585-04 for ; Mon, 30 May 2005 16:54:53 +0000 (GMT) Received: from cassarossa.samfundet.no (cassarossa.samfundet.no [129.241.93.19]) by svr1.postgresql.org (Postfix) with ESMTP id 20E7352816 for ; Mon, 30 May 2005 13:54:52 -0300 (ADT) Received: from trofast.sesse.net ([129.241.93.32]) by cassarossa.samfundet.no with esmtp (Exim 4.34) id 1DcnXL-0003ck-GE for pgsql-performance@postgresql.org; Mon, 30 May 2005 18:54:48 +0200 Received: from sesse by trofast.sesse.net with local (Exim 3.36 #1 (Debian)) id 1DcnXL-0002ek-00 for ; Mon, 30 May 2005 18:54:47 +0200 Date: Mon, 30 May 2005 18:54:47 +0200 From: "Steinar H. Gunderson" To: pgsql-performance@postgresql.org Subject: Re: Postgresql and xeon. Message-ID: <20050530165447.GA9708@uio.no> Mail-Followup-To: pgsql-performance@postgresql.org References: <200505300919.40827.josh@agliodbs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <200505300919.40827.josh@agliodbs.com> X-Operating-System: Linux 2.6.11.8 on a i686 X-Message-Flag: Outlook? --> http://www.mozilla.org/products/thunderbird/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.327 tagged_above=0 required=5 tests=AWL, URIBL_SBL X-Spam-Level: X-Archive-Number: 200505/438 X-Sequence-Number: 12602 On Mon, May 30, 2005 at 09:19:40AM -0700, Josh Berkus wrote: > Search the archives of this list. This has been discussed ad nauseum. > www.pgsql.ru I must admit I still haven't really understood it -- I know that it appears on multiple operating systems, on multiple architectures, but most with Xeon CPUs, and that it's probably related to the poor memory bandwidth between the CPUs, but that's about it. I've read the threads I could find on the list archives, but I've yet to see somebody pinpoint exactly what in PostgreSQL is causing this. Last time someone claimed this was bascially understood and "just a lot of work to fix", I asked for pointers to a more detailed analysis, but nobody answered. Care to explain? :-) /* Steinar */ -- Homepage: http://www.sesse.net/