Message-ID: <482C3FB4.6050102@cheapcomplexdevices.com>
Date: Thu, 15 May 2008 06:50:44 -0700
From: Ron Mayer <rm_pg@cheapcomplexdevices.com>
User-Agent: Mozilla-Thunderbird 2.0.0.12 (X11/20080420)
MIME-Version: 1.0
To: Matthew Wakeling <matthew@flymine.org>
CC: pgsql-performance@postgresql.org
Subject: Re: I/O on select count(*)
References: <C451C651.5EE8B%llonergan@greenplum.com>
	<Pine.LNX.4.64.0805151337460.16756@aragorn.flymine.org>
In-Reply-To: <Pine.LNX.4.64.0805151337460.16756@aragorn.flymine.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Matthew Wakeling wrote:
> On Thu, 15 May 2008, Luke Lonergan wrote:
>> ...HINT bit optimization, but avoids this whole ³write the data,
>> write it to the log also, then write it again just for good measure²
> ...
> The hint data will be four bits per tuple plus overheads, so it could be 
> made very compact, and therefore likely to stay in the cache fairly 
> well. 

Does it seem like these HINT bits would be good candidates to move
off to map forks similar to how the visibility map stuff will be handled?

Since (if I understand right) only the hint bits change during the
select(*) it seems a lot less write-IO would happen if such a map
were updated rather than the data pages themselves.