| From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
|---|---|
| To: | Tom Lane <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-06 08:24:55 |
| Message-ID: | Pine.OSF.4.61.0503060923210.1725@kosh.hut.fi |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2005-03-06 10:05:12 | Re: Cost of XLogInsert CRC calculations |
| Previous Message | Jim C. Nasby | 2005-03-06 07:13:00 | Re: Missing coalesce |