Re: pgbench stats per script & other stuff - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: pgbench stats per script & other stuff
Date
Msg-id alpine.DEB.2.10.1507220706260.5636@sto
Whole thread Raw
In response to Re: pgbench stats per script & other stuff  (Josh Berkus <josh@agliodbs.com>)
List 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.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: creating extension including dependencies
Next
From: Michael Paquier
Date:
Subject: Re: Use pg_rewind when target timeline was switched