> 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.
Current implementation of pgbench allows Pgpool-II (or any proxy type
middle ware) to test the behavior on PostgreSQL clusters. For example
it sends write queries to the master DB node and read queries to
standby nodes to distribute loads among DB nodes.
With the proposed implementation it is not possible to do that kind of
test anymore since everything is packed into a function.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
