From: | Alik Khilazhev <a(dot)khilazhev(at)postgrespro(dot)ru> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [WIP] Zipfian distribution in pgbench |
Date: | 2017-08-13 12:13:10 |
Message-ID: | 5FD3F866-CA30-4634-9D48-DE669A84248C@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Fabien,
>
> I think that this method should be used for a>1, and the other very rough one can be kept for parameter a in [0, 1), a case which does not make much sense to a mathematician as it diverges if unbounded.
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”.
So should upper bound for “a" be set?
Should I mention in docs that there are two algorithms are used depending on values of a(s/theta)?
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?
Attachment | Content-Type | Size |
---|---|---|
pgbench-zipf-06v.patch | application/octet-stream | 9.0 KB |
unknown_filename | text/plain | 119 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Christoph Berg | 2017-08-13 13:01:27 | initdb failure on Debian sid/mips64el in EventTriggerEndCompleteQuery |
Previous Message | Gavin Flower | 2017-08-13 09:02:40 | Re: Patches I'm thinking of pushing shortly |