Hello Tom,
>>> I'm also highly dubious about labeling this script "standard TPC-B",
>>> when it resolves only some of the reasons why our traditional script
>>> is not really TPC-B. That's treading on being false advertising.
>
>> IANAL, but it may not even be permissible to claim that we have
>> implemented "standard TPC-B".
>
> Yeah, very likely you can't legally say that unless the TPC
> has certified your test. (Our existing code and docs are quite
> careful to call pgbench's version "TPC-like" or similar weasel
> wording, and never claim that it is really TPC-B or even a close
> approximation.)
Hmmm.
I agree that nobody really cares about TPC-B per se. The point of this
patch is to provide a built-in example of recent and useful pgbench
features that match a real specification.
The "strict" only refers to the test script. It cannot match the whole
spec which addresses many other things, some of them more process than
tool: table creation and data types, performance data collection, database
configuration, pricing of hardware used in the tests, post-benchmark run
checks, auditing constraints, whatever…
> [about pgbench] it's got too many "features" already.
I disagree with this judgement.
Although not all features are that useful, the accumulation of recent
additions (int/float/bool expressions, \if, \gset, non uniform prng, …)
makes it suitable for testing various realistic scenarii which could not
be tested before. As said above, my point was to have a builtin
illustration of available capabilities.
It did not occur to me that a scripts which implements "strictly" a
particular section of a 25-year obsolete benchmark could raise any legal
issue.
--
Fabien.
