Re: CPU costs of random_zipfian in pgbench

Fabien COELHO <coelho@cri.ensmp.fr>

From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Georgios Kokolatos <gkokolatos@pm.me>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2019-03-23T18:11:44Z
Lists: pgsql-hackers

Attachments

Hello again,

>> I started to look through this, and the more I looked the more unhappy
>> I got that we're having this discussion at all.  The zipfian support
>> in pgbench is seriously over-engineered and under-documented.  As an
>> example, I was flabbergasted to find out that the end-of-run summary
>> statistics now include this:
>>
>>    /* Report zipfian cache overflow */
>>    for (i = 0; i < nthreads; i++)
>>    {
>>        totalCacheOverflows += threads[i].zipf_cache.overflowCount;
>>    }
>>    if (totalCacheOverflows > 0)
>>    {
>>        printf("zipfian cache array overflowed %d time(s)\n", 
>> totalCacheOverflows);
>>    }
>> 
>> 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.

-- 
Fabien.

Commits

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

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