On 07/21/2015 10:25 PM, Fabien COELHO wrote:
>
> 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.
Maybe not.
If so, I would vote for:
-f script1.bench:3 -f script2.bench:1
over:
-f script1.bench -w 3 -f script2.bench -w 1
Making command-line options order-dependant breaks a lot of system call
libraries in various languages, as well as being easy to mess up.
>> 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:
Oh, you misunderstand. "script1" and "script2" are meant to be
user-supplied names which then get reported in things like response time
output. They're labels. Better example:
deposit:file: deposit.benchweight: 3
withdrawal:file: withdrawal.benchweight: 3
reporting:file: summary_report.benchweigh: 1
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
