Re: CPU costs of random_zipfian in pgbench
Fabien COELHO <coelho@cri.ensmp.fr>
From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Ants Aasma <ants.aasma@eesti.ee>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-02-22T16:10:02Z
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.
Commits
-
Remove now-unnecessary thread pointer arguments in pgbench.
- d8c0bd9fefa9 12.0 landed
-
Restrict pgbench's zipfian parameter to ensure good performance.
- 26a76cb64072 12.0 landed