Re: pgbench stats per script & other stuff

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgbench stats per script & other stuff
Date: 2015-07-22 05:25:58
Message-ID: alpine.DEB.2.10.1507220706260.5636@sto
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Josh,

>> Maybe -f file.sql:weight (yuk from my point of view, but it can be done
>> easily).
>
> Maybe it's past time for pgbench to have a config file?

That is an idea. For "simple" usage, for backward compatibility and for
people like me who like them, ISTM that options are fine too:-)

Also this may mean adding a dependency to some YAML library, configure
issues (I'm not sure whether pg currently uses YAML, and JSON is quite
verbose), maybe conditionals around the feature to compile without the
dependency, more documentation...

I'm not sure all that is desirable just for weighting scripts.

> Given that we want to define some per-workload options, the config file
> would probably need to be YAML or JSON, e.g.:
>
> [...]
>
> script1:
> file: script1.bench
> weight: 3
> script2:
> file: script2.bench
> weight: 1
>
> the above would execute a pgbench with 16 clients, 4 threads, "script1"
> three times as often as script2, and report stats at the script (rather
> than SQL statement) level.

Yep. Probably numbering within field names should be avoided, so a list of
records that could look like:

scripts:
- file: foo1.sql
weight: 9
- file: foo2.sql
- internal: tpc-b
weight: 2

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2015-07-22 05:48:06 Re: Use pg_rewind when target timeline was switched
Previous Message Michael Paquier 2015-07-22 05:12:19 Re: creating extension including dependencies