Fabien COELHO <coe...@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