Re: [REVIEW] Re: Compression of full-page-writes - Mailing list pgsql-hackers

From Ants Aasma
Subject Re: [REVIEW] Re: Compression of full-page-writes
Date
Msg-id CA+CSw_sieQzzUp45Wt0hEBD1JqRi2Zr6Vn4Q12Z5bpMGKmD8-Q@mail.gmail.com
Whole thread Raw
In response to Re: [REVIEW] Re: Compression of full-page-writes  (Arthur Silva <arthurprs@gmail.com>)
Responses Re: [REVIEW] Re: Compression of full-page-writes
Re: [REVIEW] Re: Compression of full-page-writes
List pgsql-hackers
On Sat, Sep 13, 2014 at 6:59 AM, Arthur Silva <arthurprs@gmail.com> wrote:
> That's not entirely true. CRC-32C beats pretty much everything with the same
> length quality-wise and has both hardware implementations and highly
> optimized software versions.

For better or for worse CRC is biased by detecting all single bit
errors, the detection capability of larger errors is slightly
diminished. The quality of the other algorithms I mentioned is also
very good, while producing uniformly varying output. CRC has exactly
one hardware implementation in general purpose CPU's and Intel has a
patent on the techniques they used to implement it. The fact that AMD
hasn't yet implemented this instruction shows that this patent is
non-trivial to work around. The hardware CRC is about as fast as
xxhash. The highly optimized software CRCs are an order of magnitude
slower and require large cache trashing lookup tables.

If we choose to stay with CRC we must accept that we can only solve
the performance issues for Intel CPUs and provide slight alleviation
for others.

Regards,
Ants Aasma
--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Stating the significance of Lehman & Yao in the nbtree README
Next
From: Fabien COELHO
Date:
Subject: Re: pgbench throttling latency limit