On Sun, Aug 27, 2017 at 12:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jeff Janes <jeff.janes@gmail.com> writes:
>> It is easy to package 5 of those commands into a single PL/pgSQL function,
>> with the other two being implicit via the standard auto-commit behavior
>> when explicit transactions are not opened. The attached patch does that,
>> under the name tpcb-func. I first named it tpcb-like-func, but one builtin
>> name can't be a prefix or another so that won't work.
>
> 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.
Performance comparison between major releases matters only if the same
set of tests is used.
>> Wanting to measure IPC overhead is a valid thing to do, but
>> certainly isn't the most common thing people want to do with pgbench.
>
> I think that's nonsense. Measuring how fast PG can do client interactions
> is EXACTLY what this is about. Certainly, pushing SQL operations into
> server-side functions is a great way to reduce network overhead, but it
> has nothing to do with what we choose as a benchmark.
This thread makes me think that it would be a good idea to add in the
documentation of pgbench a section that gives out a set of scripts
that can be used for emulating more patterns instead of having them in
the code. The proposed test has value if one would like to compare if
it is better for an application to move more things server-side if
there is a lot of latency with the existing tpcb test of pgbench, but
that's not the end of it.
--
Michael
