Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id C466C2E0031 for ; Fri, 16 May 2008 23:45:15 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 24624-09 for ; Fri, 16 May 2008 23:45:06 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by developer.postgresql.org (Postfix) with ESMTP id 9A9062E002E for ; Fri, 16 May 2008 23:45:12 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m4H2j2kT018383; Fri, 16 May 2008 22:45:02 -0400 (EDT) To: Alvaro Herrera cc: Greg Smith , Matthew Wakeling , pgsql-performance@postgresql.org Subject: Re: I/O on select count(*) In-reply-to: <20080516201528.GJ13061@alvh.no-ip.org> References: <920841.71690.qm@web44808.mail.sp1.yahoo.com> <482B1D5F.EE98.0025.0@wicourts.gov> <20080515020553.GN9838@alvh.no-ip.org> <20080515155232.GC8221@alvh.no-ip.org> <20080516201528.GJ13061@alvh.no-ip.org> Comments: In-reply-to Alvaro Herrera message dated "Fri, 16 May 2008 16:15:28 -0400" Date: Fri, 16 May 2008 22:45:02 -0400 Message-ID: <18382.1210992302@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200805/261 X-Sequence-Number: 30229 Alvaro Herrera writes: > Greg Smith wrote: >> After reading the code and that documentation a bit, the part I'm still >> not sure about is whether the CLOG entry is created when the XID is >> assigned and then kept current as the state changes, or whether that >> isn't even in CLOG until the transaction is committed. > pg_clog is allocated in pages of 8kB apiece(*). On allocation, pages are > zeroed, which is the bit pattern for "transaction in progress". So when > a transaction starts, it only needs to ensure that the pg_clog page that > corresponds to it is allocated, but it need not write anything to it. One additional point: this means that one transaction in every 32K writing transactions *does* have to do extra work when it assigns itself an XID, namely create and zero out the next page of pg_clog. And that doesn't just slow down the transaction in question, but the next few guys that would like an XID but arrive on the scene while the zeroing-out is still in progress. This probably contributes to the behavior that Simon and Josh regularly complain about, that our transaction execution time is subject to unpredictable spikes. I'm not sure how to get rid of it though. regards, tom lane