> I liked @ because it makes sense to read it as the word "at".
Yep, why not.
>> Prepending classic to the names does not look necessary. I would
>> suggest "tpcb-like", "simple-update" & "select-only", or even maybe any
>> prefix. If the bench scripts could be read from some pg directory
>> instead of being actually inlined, even more code could be dropped from
>> pgbench.
>
> I think including classic would be a very good idea.
Hmm. This is the command line, you have to type them! With a prefix-based
approach this suggests that the builtin names must start differently so as
to be easily selected.
> We might want to add a TPC-C like workload in the future, or any number
> of other things. Naming things in a good way from the outset can only
> make that easier.
Here is a v4 which:
- removes -w stuff
- enhance -f with @weight
- adds -b/--builtin name@weight, based on prefix
builtin names are: tpcb-like, simple-update & select-only, which matches their more or less historical names
(althoughI wasn't sure of "tpcb-sort-of", so I put "tpcb-like")
- removes -B (now can be accessed with -b tpcb-like)
Pgbench builtin scripts are still inlined in the code, not in a separate
directory, which might be an option to simplify the code and allow easy
extensions.
I still think that the "--per-script-stats" option is useless and per
script stats should always be on as soon as several scripts are running.
Even more, I think that stats (maybe no per-command stat though) should
always be collected. The point of pgbench is to collect data, and the
basic end-of-run tps summary is very terse and does not reflect much
of what happened during the run.
Also, maybe per-command detailed stats should use the same common struct
to hold data as all other stats. I did not change it because it is
maintained in a different part of the code.
--
Fabien.
