Re: Cost of XLogInsert CRC calculations - Mailing list pgsql-hackers

From Mark Cave-Ayland
Subject Re: Cost of XLogInsert CRC calculations
Date
Msg-id 9EB50F1A91413F4FA63019487FCD251D113169@WEBBASEDDC.webbasedltd.local
Whole thread Raw
In response to Cost of XLogInsert CRC calculations  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Cost of XLogInsert CRC calculations  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi Tom,

> I was profiling a case involving UPDATEs into a table with too many
indexes (brought to > mind by mysql's sql-bench, about which more later) and
got this rather surprising result > for routines costing more than 1% of the
total runtime:

(cut)

> 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.

Wow, a 64-bit CRC does seem excessive, especially when going back to Zmodem
days where a 50-100k file seemed to be easily protected by a 32-bit CRC. I'm
sure there are some error rates somewhere dependent upon the polynomial and
the types of error detected.... Try the following link towards the bottom:
http://www.ee.unb.ca/tervo/ee4253/crc.htm for some theory on detection rates
vs. CRC size.


Kind regards,

Mark.

------------------------
WebBased Ltd
South West Technology Centre
Tamar Science Park
Plymouth
PL6 8BT

T: +44 (0)1752 791021
F: +44 (0)1752 791023
W: http://www.webbased.co.uk




pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: buildfarm issues
Next
From: Dave Cramer
Date:
Subject: get generated keys and insert returning