Re: [REVIEW] Re: Compression of full-page-writes

Поиск
Список
Период
Сортировка
От Ants Aasma
Тема Re: [REVIEW] Re: Compression of full-page-writes
Дата
Msg-id CA+CSw_sieQzzUp45Wt0hEBD1JqRi2Zr6Vn4Q12Z5bpMGKmD8-Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [REVIEW] Re: Compression of full-page-writes  (Arthur Silva <arthurprs@gmail.com>)
Ответы Re: [REVIEW] Re: Compression of full-page-writes  (Andres Freund <andres@2ndquadrant.com>)
Re: [REVIEW] Re: Compression of full-page-writes  (Florian Weimer <fw@deneb.enyo.de>)
Список 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 по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Stating the significance of Lehman & Yao in the nbtree README
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: pgbench throttling latency limit