> On 27 Aug 2017, at 08:37, Fabien COELHO wrote:
>
>
> About the patch:
>
> I'm generally in favor of providing more options to pgbench, especially if it
> can give optimization ideas to the performance conscious user.
>
> I think that the name should be "tpcb-like-plfunc": the script does no
On Sun, Aug 27, 2017 at 12:16 PM, Tom Lane wrote:
> Jeff Janes 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 th
> Don't think anybody is proposing to remove the existing way to run
> pgbench, so I'm not sure what your point is?
I know. I just wanted to point out that the proposal is not good for
cluster environment tests.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/in
Hi,
On 2017-08-28 08:05:11 +0900, Tatsuo Ishii wrote:
> With the proposed implementation it is not possible to do that kind of
> test anymore since everything is packed into a function.
Don't think anybody is proposing to remove the existing way to run
pgbench, so I'm not sure what your point is?
> Jeff Janes 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. Ther
About the patch:
I'm generally in favor of providing more options to pgbench, especially if
it can give optimization ideas to the performance conscious user.
I think that the name should be "tpcb-like-plfunc": the script does not
implement tpcb per spec, and such a function could be written
Hello Tom,
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
no
Hello,
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.
Sure. The throughput of
Jeff Janes 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
On Sat, Aug 26, 2017 at 4:59 PM, Jeff Janes wrote:
> I still get a 2 fold improvement, from 13668 to 27036, when both
> transactions are tested with -M prepared.
>
> I am surprised, I usually haven't seen that much difference for the default
> queries between prepared or not, to the point that I g
On Sat, Aug 26, 2017 at 4:28 PM, Peter Geoghegan wrote:
> On Sat, Aug 26, 2017 at 3:53 PM, Jeff Janes wrote:
> > I get nearly a 3 fold speed up using the new transaction, from 9184 to
> 26383
> > TPS, on 8 CPU machine using scale 50 and:
> >
> > PGOPTIONS="-c synchronous_commit=off" pgbench -c32
On Sat, Aug 26, 2017 at 3:53 PM, Jeff Janes wrote:
> I get nearly a 3 fold speed up using the new transaction, from 9184 to 26383
> TPS, on 8 CPU machine using scale 50 and:
>
> PGOPTIONS="-c synchronous_commit=off" pgbench -c32 -j32 -T60 -b tpcb-like
What about with "-M prepared"? I think that m
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.
13 matches
Mail list logo
