Fabien COELHO <coelho@cri.ensmp.fr> writes:
>>> I'd suggest that maybe we should get rid of the use of both random()
>>> and srandom() in pgbench, and go over to letting set_random_seed()
>>> fill the pg_erand48 state directly.
> Here is a POC which defines an internal interface for a PRNG, and use it
> within pgbench, with several possible implementations which default to
> rand48.
I seriously dislike this patch. pgbench's random support is quite
overengineered already IMO, and this proposes to add a whole batch of
new code and new APIs to fix a very small bug.
> I must admit that I have a grudge against standard rand48:
I think this is nonsense, particularly the claim that anything in PG
cares about the lowest-order bits of random doubles. I'm aware that
there are applications where that does matter, but people aren't doing
high-precision weather simulations in pgbench.
BTW, did you look at the question of the range of zipfian? I confirmed
here that as used in the test case, it's generating a range way smaller
than the other ones: repeating the insertion snippet 1000x produces stats
like this:
regression=# select seed,rand,min(val),max(val),count(distinct val) from seeded_random group by 1,2 order by 2,1;
seed | rand | min | max | count
------------+-------------+------+------+-------
1957482663 | exponential | 2000 | 2993 | 586
1958556409 | exponential | 2000 | 2995 | 569
1959867462 | exponential | 2000 | 2997 | 569
1957482663 | gaussian | 3009 | 3997 | 493
1958556409 | gaussian | 3027 | 3956 | 501
1959867462 | gaussian | 3018 | 3960 | 511
1957482663 | uniform | 1001 | 1999 | 625
1958556409 | uniform | 1000 | 1999 | 642
1959867462 | uniform | 1001 | 1999 | 630
1957482663 | zipfian | 4000 | 4081 | 19
1958556409 | zipfian | 4000 | 4022 | 18
1959867462 | zipfian | 4000 | 4156 | 23
I have no idea whether that indicates an actual bug, or just poor
choice of parameter in the test's call. But the very small number
of distinct outputs is disheartening at least.
regards, tom lane
