On Wed, Mar 27, 2019, 15:57 Christoph Berg <m...@debian.org> wrote: > Re: To Tom Lane 2019-03-26 <20190326151446.gg3...@msg.df7cb.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 >