Re: CPU costs of random_zipfian in pgbench

On 2019-Apr-01, Tom Lane wrote:

> Fabien COELHO <coelho@cri.ensmp.fr> writes:
> >> I was wondering about that too.  It seems like it'd be a wise idea to
> >> further constrain s and/or n to ensure that the s > 1 code path doesn't do
> >> anything too awful ...
> 
> > Yep. The attached version enforces s >= 1.001, which avoids the worse cost
> > of iterating, according to my small tests.
> 
> Seems reasonable.  Pushed with minor documentation editing.

Ah, so we now we can get rid of the TState * being passed around
separately for expression execution, too?

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services