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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
