From: Ron Mayer <rm_pg@cheapcomplexdevices.com>
To: Matthew Wakeling <matthew@flymine.org>
Cc: pgsql-performance@postgresql.org
Subject: Re: I/O on select count(*)
Date: Thu, 15 May 2008 06:50:44 -0700
Message-ID: <482C3FB4.6050102@cheapcomplexdevices.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0805151337460.16756@aragorn.flymine.org>
References: <C451C651.5EE8B%llonergan@greenplum.com>
<Pine.LNX.4.64.0805151337460.16756@aragorn.flymine.org>
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.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: rm_pg@cheapcomplexdevices.com, matthew@flymine.org
Subject: Re: I/O on select count(*)
In-Reply-To: <482C3FB4.6050102@cheapcomplexdevices.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox