Re: Enable data checksums by default

Поиск
Список
Период
Сортировка
От Ants Aasma
Тема Re: Enable data checksums by default
Дата
Msg-id CA+CSw_twXdRzDN2XsSZBxEj63DeZ+f6_hs3Qf7hmXfenxSq+jg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Enable data checksums by default  (Christoph Berg <myon@debian.org>)
Ответы Re: Enable data checksums by default
Список pgsql-hackers
On Wed, Mar 27, 2019, 15:57 Christoph Berg <myon@debian.org> wrote:
Re: To Tom Lane 2019-03-26 <20190326151446.GG3829@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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: legrand legrand
Дата:
Сообщение: Re: Planning counters in pg_stat_statements (using pgss_store)
Следующее
От: Darafei "Komяpa" Praliaskouski
Дата:
Сообщение: Berserk Autovacuum (let's save next Mandrill)