Re: Page Checksums

From: Jesper Krogh <jesper(at)krogh(dot)cc>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Page Checksums
Date: 2011-12-20 18:44:53
Message-ID: 4EF0D7A5.1040100@krogh.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2011-12-19 02:55, Greg Stark wrote:
> On Sun, Dec 18, 2011 at 7:51 PM, Jesper Krogh<jesper(at)krogh(dot)cc> wrote:
>> I dont know if it would be seen as a "half baked feature".. or similar,
>> and I dont know if the hint bit problem is solvable at all, but I could
>> easily imagine checksumming just "skipping" the hit bit entirely.
> That was one approach discussed. The problem is that the hint bits are
> currently in each heap tuple header which means the checksum code
> would have to know a fair bit about the structure of the page format.
> Also the closer people looked the more hint bits kept turning up
> because the coding pattern had been copied to other places (the page
> header has one, and index pointers have a hint bit indicating that the
> target tuple is deleted, etc). And to make matters worse skipping
> individual bits in varying places quickly becomes a big consumer of
> cpu time since it means injecting logic into each iteration of the
> checksum loop to mask out the bits.
I do know it is a valid and really relevant point (the cpu-time spend),
but here in late 2011 it is really a damn irritating limitation, since if
there any resources I have plenty available of in the production environment
then it is cpu-time, just not on the "single core currently serving the
client".

Jesper
--
Jesper

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2011-12-20 18:59:04 Re: PATCH: tracking temp files in pg_stat_database
Previous Message Claes Jakobsson 2011-12-20 18:39:54 Re: JSON for PG 9.2