> -----Original Message----- > From: Tom Lane [mailto:[EMAIL PROTECTED] > Sent: 10 May 2005 23:22 > To: Simon Riggs > Cc: Bruce Momjian; Mark Cave-Ayland (External); > pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Cost of XLogInsert CRC calculations
(cut) > That's awfully vague --- can't you give any more detail? > > I have seen XLogInsert eating significant amounts of time (up > to 10% of total CPU time) on non-Intel architectures, so I > think that dropping down to 32 bits is warranted in any case. > But if you are correct then that might not fix the problem > on Intel machines. We need more info. > > regards, tom lane Hi Tom/Simon, Just for the record, I found a better analysis of Adler-32 following some links from Wikipedia. In summary, the problem with Adler-32 is that while it is only slightly less sensitive than CRC-32, it requires roughly a 1k "run-in" in order to attain full coverage of the bits (with respect to sensitivity of the input). This compares to 4 bytes of "run-in" required for CRC-32. So unless we can guarantee a minimum of 1k data per Xlog record then Adler-32 won't be suitable. See the following two links for more information: http://en.wikipedia.org/wiki/Adler-32 http://www.ietf.org/rfc/rfc3309.txt One other consideration would be that since CRC-32 calculations for Xlog records occur so often, perhaps the CRC-32 routines could be written in in-line assembler, falling back to C for unsupported processors. It would be interesting to come up with some benchmarks to see if indeed this would be faster than the current C implementation, since as the routine is called so often it could add up to a significant saving under higher loads. Kind regards, Mark. ------------------------ WebBased Ltd 17 Research Way Plymouth PL6 8BT T: +44 (0)1752 791021 F: +44 (0)1752 791023 W: http://www.webbased.co.uk ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
