Horton

Re: CPU costs of random_zipfian in pgbench

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>, Georgios Kokolatos <gkokolatos@pm.me>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2019-04-01T21:39:05Z
Lists: pgsql-hackers 
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.

			regards, tom lane

Commits

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

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