Hello Andrey,
>> - NOT to invent a new design!
>
> Radical version of this argument would be to use de-facto standard and
> ubiquitous MT19937.
Indeed, I started considering this one for this reason, obviously.
> Though, I suspect, it's not optimal solution to the date.
"not optimal" does not do justice to the issues.
The main one is the huge 2.5 KB state of MT19937 which makes it quite
impractical for plenty of internal and temporary uses. In pgbench there
are many PRNG needed for reproducibility (eg one global, 3 per thread, one
per client) plus a temporary one internal to a function call (permute)
which is expected to be reasonably fast, so should not start by
initializing 2.5 KB of data. In postgres there are 2 permanent ones (sql
random, C double random) plus some in a geqo and in sampling internal
structures.
So standard MT19937 is basically out of the equation. It also happens to
fail some statistical tests and not be very fast. It has a insanely huge
cycle, but pg does not need that, and probably nobody does. The only good
point is that it is a standard, which IMO is not enough to fix the other
issues.
--
Fabien.
