Re: [HACKERS] pgbench: faster version of tpcb-like transaction

Jeff Janes <jeff.janes@gmail.com> writes:
> If all the data is in memory and you have a system with fast fsyncs (or are
> running with fsync off, or unlogged tables, or synchronous_commit off),
> then the big bottleneck in pgbench is the amount of back and forth between
> the pgbench program and the backend.  There are 7 commands per transaction.

Yeah ...

> 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.

> 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.
        regards, tom lane