From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgbench: faster version of tpcb-like transaction |
Date: | 2017-08-27 03:16:02 |
Message-ID: | 24631.1503803762@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jeff Janes <jeff(dot)janes(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2017-08-27 05:45:21 | Re: pgbench: faster version of tpcb-like transaction |
Previous Message | Tom Lane | 2017-08-27 03:03:52 | Re: More replication race conditions |