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

  1. Remove now-unnecessary thread pointer arguments in pgbench.

  2. Restrict pgbench's zipfian parameter to ensure good performance.