Re: CPU costs of random_zipfian in pgbench

>>>>> What is the point of that, and if there is a point, why is it nowhere
>>>>> mentioned in pgbench.sgml?
>>>
>>> The attached patch simplifies the code by erroring on cache overflow,
>>> instead of the LRU replacement strategy and unhelpful final report.
>>> The above lines are removed.
>
> Eh? Do I understand correctly that pgbench might start failing after
> some random amount of time, instead of reporting the overflow at the
> end?

Indeed, that what this patch would induce, although very probably under a 
*short* random amount of time.

> I'm not sure that's really an improvement ...

Depends. If the cache is full it means repeating the possibly expensive 
constant computations, which looks like a very bad idea for the user 
anyway.

> Why is the cache fixed-size at all?

The cache can diverge and the search is linear, so it does not seem a good 
idea to keep it for very long:

   \set size random(100000, 1000000)
   \set i random_zipfian(1, :size, ...)

The implementation only makes some sense if there are very few values 
(param & size pairs with param < 1) used in the whole script.

Tom is complaining of over engineering, and he has a point, so I'm trying 
to simplify (eg dropping LRU and erroring) for cases where the feature is 
not really appropriate anyway.

-- 
Fabien.