| From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Gurjeet Singh" <singh(dot)gurjeet(at)gmail(dot)com>, "PGSQL Hackers" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: New CRC algorithm: Slicing by 8 |
| Date: | 2006-10-23 17:44:53 |
| Message-ID: | 1161625493.3861.66.camel@silverbirch.site |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, 2006-10-22 at 18:06 -0400, Tom Lane wrote:
> These numbers are um, not impressive. Considering that a large fraction
> of our WAL records are pretty short, the fact that slice8 consistently
> loses at short buffer lengths is especially discouraging. Much of that
> ground could be made up perhaps with tenser coding of the initialization
> and finalization code, but it'd still not be worth taking any legal risk
> for AFAICS.
It doesn't look good for SB8, does it? Nor for gcc4.1 either.
Presumably Intel themselves will have some come-back, but I'm not sure
what they'll so to so many conclusive tests.
Instead, I'd like to include a parameter to turn off CRC altogether, for
heavily CPU bound operations and the WAL drive on trustworthy hardware.
wal_checksum = off
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-10-23 17:52:41 | Re: New CRC algorithm: Slicing by 8 |
| Previous Message | Jonah H. Harris | 2006-10-23 17:29:49 | Re: PgSQL users quota |