| From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
|---|---|
| To: | Alik Khilazhev <a(dot)khilazhev(at)postgrespro(dot)ru> |
| Cc: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [WIP] Zipfian distribution in pgbench |
| Date: | 2017-08-13 17:57:20 |
| Message-ID: | alpine.DEB.2.20.1708131946130.14137@lancre |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello Alik,
> Now “a” does not have upper bound, that’s why on using iterative algorithm with a >= 10000 program will stuck on infinite loop 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-08-13 18:04:41 | Re: Server crash (FailedAssertion) due to catcache refcount mis-handling |
| Previous Message | Tom Lane | 2017-08-13 15:38:09 | Re: initdb failure on Debian sid/mips64el in EventTriggerEndCompleteQuery |