From: | Ants Aasma <ants(dot)aasma(at)eesti(dot)ee> |
---|---|
To: | Christoph Berg <myon(at)debian(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Enable data checksums by default |
Date: | 2019-03-27 20:51:16 |
Message-ID: | CA+CSw_twXdRzDN2XsSZBxEj63DeZ+f6_hs3Qf7hmXfenxSq+jg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | Postg롤 토토SQL : |
On Wed, Mar 27, 2019, 15:57 Christoph Berg <myon(at)debian(dot)org> wrote:
> Re: To Tom Lane 2019-03-26 <20190326151446(dot)GG3829(at)msg(dot)df7cb(dot)de>
> > I run a benchmark with checksums disabled/enabled. shared_buffers is
> > 512kB to make sure almost any read will fetch the page from the OS
> > cache; scale factor is 50 (~750MB) to make sure the whole cluster fits
> > into RAM.
> [...]
> > So the cost is 5% in this very contrived case. In almost any other
> > setting, the cost would be lower, I'd think.
>
> (That was on 12devel, btw.)
>
> That was about the most extreme OLTP read-only workload. After
> thinking about it some more, I realized that exercising large seqscans
> might be an even better way to test it because of less per-query
> overhead.
>
> Same setup again, shared_buffers = 16 (128kB), jit = off,
> max_parallel_workers_per_gather = 0:
>
> select count(bid) from pgbench_accounts;
>
> no checksums: ~456ms
> with checksums: ~489ms
>
> 456.0/489 = 0.9325
>
> The cost of checksums is about 6.75% here.
>
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.
Regards,
Ants Aasma
>
From | Date | Subject | |
---|---|---|---|
Next Message | Darafei Komяpa Praliaskouski | 2019-03-27 20:54:57 | Berserk Autovacuum (let's save next Mandrill) |
Previous Message | legrand legrand | 2019-03-27 20:36:08 | Re: Planning counters in pg_stat_statements (using pgss_store) |