Re: [HACKERS] [WIP] Zipfian distribution in pgbench

Hello Alik,

> Now “a” does not have upper bound, that’s why on using iterative algorithm with a >= 10000 program will stuck on
infiniteloop because of following line of code:
 
> double b = pow(2.0, s - 1.0);
> Because after overflow “b” becomes “+Inf”.

Yep, overflow can happen.

> So should upper bound for “a" be set?

Yes, I agree. a >= 10000 does not make much sense... If you want uniform 
you should use random(), not call random_zipfian with a = 10000. Basically 
it suggests that too large values of "a" should be rejected. Not sure 
where to put the limit, though.

> Should I mention in docs that there are two algorithms are used 
> depending on values of a(s/theta)?

Yes, as a general principle I think that the documentation should reflect 
the implementation.

> In attaching patch, I have added computeIterativeZipfian method and it’s 
> usage in getZipfianRand. Is it better to move code of computing via 
> cache to new method, so that getZipfianRand will contain only 2 
> computeXXXZipfian method calls?

I have not looked in detail, but from what you say I would agree that the 
implementation should be symmetric, so having one function calling one 
method or the other sounds good.

-- 
Fabien.