Re: Enable data checksums by default

From: Ants Aasma <ants(dot)aasma(at)eesti(dot)ee>
To: Christoph Berg <myon(at)debian(dot)org>, Ants Aasma <ants(dot)aasma(at)eesti(dot)ee>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Enable data checksums by default
Date: 2019-03-29 11:18:14
Message-ID: CA+CSw_s8NT_crvXCKiTb80hxD=YzZDfzyMt3=kBM6AP0TLxeVQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 28, 2019 at 10:38 AM Christoph Berg <myon(at)debian(dot)org> wrote:

> Re: Ants Aasma 2019-03-27 <
> CA+CSw_twXdRzDN2XsSZBxEj63DeZ+f6_hs3Qf7hmXfenxSq+jg(at)mail(dot)gmail(dot)com>
> > Can you try with postgres compiled with CFLAGS="-O2 -march=native"?
> There's
> > a bit of low hanging fruit there to use a runtime CPU check to pick a
> > better optimized checksum function.
>
> Frankly, no. This is with the apt.pg.o packages which are supposed to
> be usable by everyone. If there is a better per-CPU checksum function,
> PG should pick it at runtime. Special compiler flags are a no-go here.
>

I went ahead and tested it on the count(*) test, same settings as upthread.
Median of 5 runs of 20txs on Intel i5-2500k @ 4GHz.

No checksum: 344ms
Checksums: 384ms (+12%)
No checksum march=native: 344ms
Checksums march=native: 369ms (+7%)

The checksum code was written to be easily auto-vectorized by the compiler.
So if we just compile the same function with different compiler flags and
pick between them at runtime the overhead can be approximately halved. Not
saying that this needs to be done before enabling checksums by default,
just that when considering overhead, we can foresee it being much lower in
future versions.

Regards,
Ants Aasma

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Prabhat Sahu 2019-03-29 11:25:26 Inconsistencies in the behavior of CHR() function in PG.
Previous Message Thomas Munro 2019-03-29 11:13:23 Re: pg_ctl on windows can't open postmaster.pid: Permission denied