Re: what checksum algo?

> Well, off the top of my head I would of course be sure to build
> Postgres to take advantage of this:
>
> * Vectorization of the algorithm requires 32bit x 32bit -> 32bit integer
> * multiplication instruction. As of 2013 the corresponding instruction is
> * available on x86 SSE4.1 extensions (pmulld) and ARM NEON (vmul.i32).
> * Vectorization requires a compiler to do the vectorization for us. For recent
> * GCC versions the flags -msse4.1 -funroll-loops -ftree-vectorize are enough
> * to achieve vectorization.
>
> Unfortunately I have no idea what packagers are currently doing about
> this. Could you please enlighten me, Devrim?

No problem. We will install PostgreSQL from source code anyway. I
tried in my local environment, PostgreSQL compiles fine with the
addional arguments you gave me and passed regression test (of course
pg_regress.c is modified to add initdb -k flag).

> It also occurs to me that pgbench will be pretty unsympathetic to
> checksums as compared to a non-checksummed baseline here, because of
> course as always it uses a uniform distribution, and that's going to
> literally maximize the amount of verification that must occur. Maybe
> that's something you're interested in, because you want to
> characterize the worst case. If the average case is more interesting,
> you could try applying this patch:
>
> https://commitfest.postgresql.org/action/patch_view?id=1240
>
> I don't know if the patch is any good, having not looked at the code,
> but surely as the original author of pgbench you are eminently
> qualified to judge this. I think that in general I prefer a uniform
> distribution, because most often I look to pgbench to satisfy myself
> that certain types of regressions have not occurred. That's quite a
> different thing to a representative workload, obviously.

Ok, I will look into this when I have enough time.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp