> pgsql(at)mohawksoft(dot)com writes:
>>> No, it's all about time penalties and loss of concurrency.
>> I don't think that the amount of time it would take to calculate and
>> the sum is even important. It may be in older CPUs, but these days CPUs
>> are so fast in RAM and a block is very small. On x86 systems, depending
>> page alignment, we are talking about two or three pages that will be "in
>> memory" (They were used to read the block from disk or previously
> Your optimism is showing ;-). XLogInsert routinely shows up as a major
> CPU hog in any update-intensive test, and AFAICT that's mostly from the
> CRC calculation for WAL records.
> We could possibly use something cheaper than a real CRC, though. A
> word-wide XOR (ie, effectively a parity calculation) would be sufficient
> to detect most problems.
That was something that I mentioned in my first response. if the *only*
purpose of the check is to generate a "pass" or "fail" status, and not
something to be used to find where in the block it is corrupted or attempt
to regenerate the data, then we could certainly optimize the check
algorithm. A simple checksum may be good enough.
In response to
pgsql-hackers by date
|Next:||From: Reg Me Please||Date: 2008-10-01 15:54:01|
|Subject: Transactions within a function body|
|Previous:||From: Tom Lane||Date: 2008-10-01 15:36:44|
|Subject: Re: Block-level CRC checks |