Re: pgbench - implement strict TPC-B benchmark

Hello Thomas,

Thanks for the feedback.

> +   the account branch has a 15% probability to be in the same branch
> as the teller (unless
>
> I would say "... has a 15% probability of being in the same ...".  The
> same wording appears further down in the comment.

Fixed.

> I see that the parameters you propose match the TPCB 2.0 description[1], 
> [...]

Nearly:-(

While re-re-re-re-reading the spec, it was 85%, i.e. people mostly go to 
their local teller, I managed to get it wrong. Sigh. Fixed. Hopefully.

I've updated the script a little so that it is closer to spec. I've also 
changed the script definition so that it still works as expected if 
someone changes "nbranches" definition for some reason, even if this
is explicitely discourage by comments.

> I wonder if "strict" is the right name here though.  "tpcb-like-2" at 
> least leaves room for someone to propose yet another variant, and still 
> includes the "-like" disclaimer, which I interpret as a way of making it 
> clear that this benchmark and results produced by it have no official 
> TPC audited status.

Hmmm.

The -like suffix is really about the conformance of the script, not the 
rest, but that should indeed be clearer. I've expanded the comment and doc 
about this with a disclaimers, so that there is no ambiguity about what is 
expected to conform, which is only the transaction script.

I have added a comment about the non conformance of the "int" type use for 
balances in the initialization phase.

Also, on second thought, I've changed the name to "standard-tpcb", but I'm 
unsure whether it is better than "script-tpcb". There is an insentive to 
have a different prefix so that "-b t" would not complain of ambiguity 
between "tpcb-like*", which would be a regression. This is why I did not 
choose the simple "tcp". There may be a "standard-tpcb-2" anyway.

I have added a small test run in the TAP test.

On my TODO list is adding an initialization option to change the balance 
type for conformance, by using NUMERIC or integer8.

While thinking about that, an unrelated thought occured to me: adding a 
partitioned initialization variant would be nice to test the performance 
impact of partitioning easily. I should have thought of that as soon as 
partitioning was added. Added to my TODO list as well.

-- 
Fabien.