Re: pgbench stats per script & other stuff

> 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(at)weight, based on prefix

builtin names are: tpcb-like, simple-update & select-only,
which matches their more or less historical names
(although I 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.