X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id F21F69DC98E for ; Tue, 20 Dec 2005 12:02:36 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 06306-08 for ; Tue, 20 Dec 2005 12:02:35 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from stark.xeocode.com (stark.xeocode.com [216.58.44.227]) by postgresql.org (Postfix) with ESMTP id D42799DC973 for ; Tue, 20 Dec 2005 12:02:34 -0400 (AST) Received: from localhost ([127.0.0.1] helo=stark.xeocode.com) by stark.xeocode.com with smtp (Exim 3.36 #1 (Debian)) id 1Eojwb-0005iT-00; Tue, 20 Dec 2005 11:02:29 -0500 To: Tom Lane Cc: Markus Schaber , PostgreSQL Performance List Subject: Re: Read only transactions - Commit or Rollback References: <16F953410A0F1346848DCB476A989CFE01D6AF@swtexchange2.technology.de> <43A7F303.8040804@logix-tt.com> <87mziwj6na.fsf@gate450.dyndns.org> <43A7F9B9.3010906@logix-tt.com> <29672.1135093688@sss.pgh.pa.us> In-Reply-To: <29672.1135093688@sss.pgh.pa.us> From: Greg Stark Organization: The Emacs Conspiracy; member since 1992 Date: 20 Dec 2005 11:02:29 -0500 Message-ID: <87irtjah9m.fsf@stark.xeocode.com> Lines: 13 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.078 required=5 tests=[AWL=0.078] X-Spam-Score: 0.078 X-Spam-Level: X-Archive-Number: 200512/498 X-Sequence-Number: 16319 Tom Lane writes: > That surprises me too --- can you provide details on the test case so > other people can reproduce it? AFAIR the only performance difference > between SERIALIZABLE and READ COMMITTED is the frequency with which > transaction status snapshots are taken; your report suggests you were > spending 30% of the time in GetSnapshotData, which is a lot higher than > I've ever seen in a profile. Perhaps it reduced the amount of i/o concurrent vacuums were doing? -- greg