Received: from localhost (maia-2.hub.org [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id 208A59FB546 for ; Wed, 25 Jul 2007 11:21:52 -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 62586-04 for ; Wed, 25 Jul 2007 11:21:42 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from mail01.enterprisedb.com (mail01.enterprisedb.com [63.246.7.168]) by postgresql.org (Postfix) with ESMTP id E6F0A9FB544 for ; Wed, 25 Jul 2007 11:21:48 -0300 (ADT) thread-index: AcfOxyr9YH0xk784T3ukSYCmdJFNcQ== Received: from [172.24.32.45] ([62.232.55.118]) by mail01.enterprisedb.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jul 2007 10:22:01 -0400 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4073 Subject: Re: [pgsql-advocacy] 8.2 -> 8.3 performance numbers From: "Simon Riggs" To: "Merlin Moncure" Cc: "Josh Berkus" , "Jim Nasby" , "postgresql performance list" In-Reply-To: References: <73185727-AD4A-4C97-B243-ADD2EE1875B5@decibel.org> <46A0EAE3.7030305@agliodbs.com> <1185367933.4146.13.camel@ebony.site> Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 25 Jul 2007 15:22:25 +0100 Message-ID: <1185373345.4146.48.camel@ebony.site> MIME-Version: 1.0 X-Mailer: Evolution 2.8.2 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jul 2007 14:22:01.0390 (UTC) FILETIME=[2AB88CE0:01C7CEC7] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200707/343 X-Sequence-Number: 26027 On Wed, 2007-07-25 at 10:09 -0400, Merlin Moncure wrote: > On 7/25/07, Simon Riggs wrote: > > > > Should you get the chance I would appreciate a comparative test for > > TPC-E. > > > > 1. Normal TPC-E versus > > 2. TPC-E with all FKs against Fixed tables replaced with CHECK( col IN > > (VALUES(x,x,x,...))) constraints on the referencing tables. > > > > I have reasonable evidence that Referential Integrity is the major > > performance bottleneck and would like some objective evidence that this > > is the case. > > > > No rush, since it will be an 8.4 thing to discuss and improve this > > substantially in any of the ways I envisage. > > just a small 'me too' here, the RI penalty seems higher than it should > be...especially when the foreign key table is very small, and I can > see how this would impact benchmarks. Any measurements to back that up would be appreciated. "Turning it off" isn't really a valid comparison because we do want to make the checks and expect there to be some cost to that. We just want to quantify the cost to allow prioritising our efforts to improve performance on that. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com