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.