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