From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | Ants Aasma <ants(dot)aasma(at)eesti(dot)ee>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: CPU costs of random_zipfian in pgbench |
Date: | 2019-02-22 16:10:02 |
Message-ID: | alpine.DEB.2.21.1902221703350.4182@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> There are pretty good approximations for s > 1.0 using Riemann zeta
>> function and Euler derived a formula for the s = 1 case.
>
> I believe that's what random_zipfian() already uses, because for s > 1.0
> it refers to "Non-Uniform Random Variate Generation" by Luc Devroye, and
> the text references the zeta function.
Yep.
> Also, I have not observed serious issues with the s > 1.0 case (despite
> the docs seem to suggest there may be some).
The performance issue is for s > 1.0 and very close to 1.0, et
things like s = 1.000001
>> I also noticed that i is int in this function, but n is int64. That
>> seems like an oversight.
Indeed, that is a bug!
Using it for a really int64 value would be very bad, though. Maybe there
should be an error if the value is too large, because calling pow billions
of times is bad for the computer health.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2019-02-22 16:17:40 | Re: CPU costs of random_zipfian in pgbench |
Previous Message | Robert Haas | 2019-02-22 16:06:31 | Re: [patch] Add schema total size to psql \dn+ |