From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Ants Aasma <ants(dot)aasma(at)eesti(dot)ee> |
Cc: | Andreas Karlsson <andreas(at)proxel(dot)se>, Stephen Frost <sfrost(at)snowman(dot)net>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Checksums by default? |
Date: | 2017-02-24 17:47:52 |
Message-ID: | 20170224174751.GD23209@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jan 21, 2017 at 09:02:25PM +0200, Ants Aasma wrote:
> > It might be worth looking into using the CRC CPU instruction to reduce this
> > overhead, like we do for the WAL checksums. Since that is a different
> > algorithm it would be a compatibility break and we would need to support the
> > old algorithm for upgraded clusters..
>
> We looked at that when picking the algorithm. At that point it seemed
> that CRC CPU instructions were not universal enough to rely on them.
> The algorithm we ended up on was designed to be fast on SIMD hardware.
> Unfortunately on x86-64 that required SSE4.1 integer instructions, so
> with default compiles there is a lot of performance left on table. A
> low hanging fruit would be to do CPU detection like the CRC case and
> enable a SSE4.1 optimized variant when those instructions are
> available. IIRC it was actually a lot faster than the naive hardware
> CRC that is used for WAL and about on par with interleaved CRC.
Uh, I thought already did compile-time testing for SSE4.1 and used them
if present. Why do you say "with default compiles there is a lot of
performance left on table?"
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2017-02-24 18:19:02 | Re: Poor memory context performance in large hash joins |
Previous Message | Joel Jacobson | 2017-02-24 17:34:38 | Re: case_preservation_and_insensitivity = on |