Message-ID: <482EDA10.5060603@wizmail.org>
Date: Sat, 17 May 2008 14:13:52 +0100
From: Jeremy Harris <jgh@wizmail.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.8.1.12) Gecko/20080226 Fedora/2.0.0.12-1.fc7
	Thunderbird/2.0.0.12 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: I/O on select count(*)
References: <920841.71690.qm@web44808.mail.sp1.yahoo.com>
	<482B1D5F.EE98.0025.0@wicourts.gov>
	<Pine.GSO.4.64.0805142133250.27290@westnet.com>
	<20080515020553.GN9838@alvh.no-ip.org>
	<Pine.LNX.4.64.0805151245360.16756@aragorn.flymine.org>
	<20080515155232.GC8221@alvh.no-ip.org>
	<Pine.GSO.4.64.0805161118210.4987@westnet.com>
	<20080516201528.GJ13061@alvh.no-ip.org>
	<18382.1210992302@sss.pgh.pa.us>
In-Reply-To: <18382.1210992302@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tom Lane wrote:
> 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.

A thread maintaining a pool of assigned and cleared pg_clog pages, ahead
of the immediate need?    Possibly another job for an existing daemon
thread.

- Jeremy