pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: Georgios Kokolatos <gkokolatos@pm.me>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Cc: Fabien Coelho <postgresql.org@coelho.net>
Subject: Re: CPU costs of random_zipfian in pgbench
Date: Sat, 23 Mar 2019 13:01:23 -0400
Message-ID: <3703.1553360483@sss.pgh.pa.us> (raw)
In-Reply-To: <alpine.DEB.2.21.1903131048290.4059@lancre>
References: <b5e172e9-ad22-48a3-86a3-589afa20e8f7@2ndquadrant.com>
	<alpine.DEB.2.21.1902221716430.4182@lancre>
	<155246731010.16480.15850913449923768119.pgcf@coridan.postgresql.org>
	<alpine.DEB.2.21.1903131048290.4059@lancre>

Fabien COELHO <coelho@cri.ensmp.fr> writes:
> [ pgbench-zipf-doc-3.patch ]

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?  What would a user do with this information,
and how would they know what to do?

I remain of the opinion that we ought to simply rip out support for
zipfian with s < 1.  It's not useful for benchmarking purposes to have
a random-number function with such poor computational properties.
I think leaving it in there is just a foot-gun: we'd be a lot better
off throwing an error that tells people to use some other distribution.

Or if we do leave it in there, we for sure have to have documentation
that *actually* explains how to use it, which this patch still doesn't.
There's nothing suggesting that you'd better not use a large number of
different (n,s) combinations.

			regards, tom lane




view thread (33+ messages)  latest in thread

Message-ID: <3703.1553360483@sss.pgh.pa.us>
Permalink:  ../3703.1553360483@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/3703.1553360483@sss.pgh.pa.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, coelho@cri.ensmp.fr, gkokolatos@pm.me, pgsql-hackers@lists.postgresql.org, postgresql.org@coelho.net
  Subject: Re: CPU costs of random_zipfian in pgbench
  In-Reply-To: <3703.1553360483@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox