Hello Tom,
> I dunno, it seems like this proposal involves jacking up the test case
> and driving a completely different one underneath. There is no reason
> to consider that you've improved the benchmark results --- you've just
> substituted a different benchmark, one with no historical basis, and
> not a lot of field justification either.
ISTM that putting some SQL in a function and calling it is standard
practice in some classes of applications, although probably not the most
frequent.
Moreover, as far as the TPC-B benchmark is concerned, it looks like a
perflectly legitimate implementation of the benchmark: the transaction
profile (Section 1.2) is described as 4 inputs sent in and one result
returned. The fact that the SQL commands are sent one at a time by the
client to the server is a pgbench choice that I would not have done if I
wanted to show the greatest TPC-B numbers with Pg.
Nor does it mean that it is a bad idea to do so... For instance an ORM web
application might tend to generate simple unprepared CRUD queries and
interact a lot back and forth, and the default test is not to bad to
reflect that particular kind of behavior.
Basically there are different kind of application implementations and
different tests could reflect those. So I am fine with providing more
benchmarking options to pgbench, and I intend to do so once its
capabilities are improved.
A caveat I have with Jeff patch is that "tpcb-func" is a misnommer because
pgbench does NOT implement tpcb per spec, and it is my intention to
propose a variant which does implement the spec when possible. Now I think
that I'm also responsible for the prefix constraint on names...
--
Fabien.