Received: from localhost (maia-2.hub.org [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id 349E59FB290 for ; Mon, 5 Mar 2007 16:39:12 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-new, port 10024) with ESMTP id 27776-09 for ; Mon, 5 Mar 2007 16:38:56 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 378229FB256 for ; Mon, 5 Mar 2007 16:38:59 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id l25Kcp9l022075; Mon, 5 Mar 2007 15:38:51 -0500 (EST) To: Stefan Kaltenbrunner cc: Arjen van der Meijden , pgsql-performance@postgresql.org Subject: Re: [kris@obsecurity.org: Progress on scaling of FreeBSD on 8 CPU systems] In-reply-to: <45EC7AC3.2030408@kaltenbrunner.cc> References: <20070227182621.GE29041@decibel.org> <20070302150129.GF4885@alvh.no-ip.org> <45E84790.6050609@tweakers.net> <45EBF658.30907@tweakers.net> <45EC02B4.2070409@kaltenbrunner.cc> <45EC0443.1070107@tweakers.net> <45EC7AC3.2030408@kaltenbrunner.cc> Comments: In-reply-to Stefan Kaltenbrunner message dated "Mon, 05 Mar 2007 21:17:07 +0100" Date: Mon, 05 Mar 2007 15:38:51 -0500 Message-ID: <22074.1173127131@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.06 tagged_above=0 required=5 tests=AWL, BAYES_50, SPF_HELO_PASS, SPF_PASS X-Spam-Level: X-Archive-Number: 200703/96 X-Sequence-Number: 23501 Stefan Kaltenbrunner writes: > Arjen van der Meijden wrote: >> Stefan Kaltenbrunner wrote: >>> ouch - do I read that right that even after tom's fixes for the >>> "regressions" in 8.2.0 we are still 30% slower then the -HEAD checkout >>> from the middle of the 8.2 development cycle ? >> >> Yes, and although I tested about 17 different cvs-checkouts, Tom and I >> weren't really able to figure out where "it" happened. So its a bit of a >> mystery why the performance is so much worse. > double ouch - losing that much in performance without an idea WHY it > happened is really unfortunate :-( Keep in mind that Arjen's test exercises some rather narrow scenarios; IIRC its performance is mostly determined by some complicated bitmap-indexscan cases. So that "30% slower" bit certainly doesn't represent an across-the-board figure. As best I can tell, the decisions the planner happened to be making in late June were peculiarly nicely suited to his test, but not so much for other cases. regards, tom lane