From: | "Mark Cave-Ayland" <m(dot)cave-ayland(at)webbased(dot)co(dot)uk> |
---|---|
To: | <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: Cost of XLogInsert CRC calculations |
Date: | 2005-03-07 11:04:00 |
Message-ID: | 9EB50F1A91413F4FA63019487FCD251D113169@WEBBASEDDC.webbasedltd.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2005-03-07 13:06:32 | get generated keys and insert returning |
Previous Message | Pavel Stehule | 2005-03-07 09:28:57 | Re: [HACKERS] Implementation of SQLCODE and SQLERRM variables for |