From: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> |
---|---|
To: | Matthew Wakeling <matthew(at)flymine(dot)org> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: I/O on select count(*) |
Date: | 2008-05-15 13:50:44 |
Message-ID: | 482C3FB4.6050102@cheapcomplexdevices.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Jeffrey Baker | 2008-05-15 13:56:24 | Re: Update performance degrades over time |
Previous Message | Matthew Wakeling | 2008-05-15 13:38:48 | Re: I/O on select count(*) |