Horton

Re: CPU costs of random_zipfian in pgbench

Alvaro Herrera <alvherre@2ndquadrant.com>

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

Commits

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

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