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

From Tom Lane
Subject Re: Cost of XLogInsert CRC calculations
Date
Msg-id 17080.1116390331@sss.pgh.pa.us
Whole thread Raw
In response to Re: Cost of XLogInsert CRC calculations  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Cost of XLogInsert CRC calculations  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> Well, we need to understand exactly what is going on here.  I'd not
>> like to think that we dropped back from 64 to 32 bit because of one
>> possibly-minor optimization bug in one compiler on one platform.
>> Even if that compiler+platform is 90% of the market.

> But isn't it obvious that almost any problem that CRC64 is going to
> catch, CRC32 is going to catch, and we know CRC32 has to be faster than
> CRC64?

Do we know that?  The results I showed put at least one fundamentally
32bit platform (the PowerBook I'm typing this on) at dead par for 32bit
and 64bit CRCs.  We have also established that 64bit CRC can be done
much faster on 32bit Intel than it's currently done by the default
PG-on-gcc build (hint: don't use -O2 or above).  So while Mark's report
that 64bit CRC is an issue on Intel is certainly true, it doesn't
immediately follow that the only sane response is to give up 64bit CRC.
We need to study it and see what alternatives we have.

I do personally feel that 32bit is the way to go, but that doesn't
mean I think it's a done deal.  We owe it to ourselves to understand
what we are buying and what we are paying for it.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Steve Atkins
Date:
Subject: Re: Learning curves and such (was Re: pgFoundry)
Next
From: "Dann Corbit"
Date:
Subject: Re: Cost of XLogInsert CRC calculations