From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pgbench - implement strict TPC-B benchmark |
Date: | 2019-08-01 13:25:49 |
Message-ID: | CA+TgmoZfNLAoLeEi6DkhUrwaacxz0nHtZLPehA3+0s3JzMqyUg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Aug 1, 2019 at 2:53 AM Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
> All in all, pgbench overheads are small compared to postgres processing
> times and representative of a reasonably optimized client application.
It's pretty easy to devise tests where pgbench is client-limited --
just try running it with threads = clients/4, sometimes even
clients/2. So I don't buy the idea that this is true in general.
> To try to salvage my illustration idea: I could change the name to "demo",
> i.e. quite far from "TPC-B", do some extensions to make it differ, eg use
> a non-uniform random generator, and then explicitly say that it is a
> vaguely inspired by "TPC-B" and intended as a demo script susceptible to
> be updated to illustrate new features (eg if using a non-uniform generator
> I'd really like to add a permutation layer if available some day).
>
> This way, the "demo" real intention would be very clear.
I do not like this idea at all; "demo" is about as generic a name as
imaginable. But I have another idea: how about including this script
in the documentation with some explanatory text that describes (a) the
ways in which it is more faithful to TPC-B than what the normal
pgbench thing and (b) the problems that it doesn't solve, as
enumerated by Fabien upthread:
"table creation and data types, performance data collection, database
configuration, pricing of hardware used in the tests, post-benchmark run
checks, auditing constraints, whatever…"
Perhaps that idea still won't attract any votes, but I throw it out
there for consideration.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2019-08-01 13:38:40 | Re: Store FullTransactionId in TwoPhaseFileHeader/GlobalTransactionData |
Previous Message | Surafel Temesgen | 2019-08-01 12:54:11 | Re: FETCH FIRST clause PERCENT option |