On Sun, 6 Mar 2005, Tom Lane wrote:
I suppose that the bulk of the CPU cycles being attributed to XLogInsert are going into the inlined CRC calculations. Maybe we need to think twice about the cost/benefit ratio of using 64-bit CRCs to protect xlog records that are often only a few dozen bytes.
Isn't the CRC quite important on recovery to recognize where the last valid log record is?
Is there any better implementations of CRC-64? Would using a different polynomial help?
Would it help to do the CRC calculation in a more wholesale fashion in XLogWrite?
How about switching to CRC-32 or even CRC-16? I searched the archives for the reason CRC-64 was chosen in the first place. It seems that the difference in computation time was not considered to be significant, and there was 8 bytes available in the record header anyway.
Just some thoughts...
- Heikki
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
