Skip site navigation (1) Skip section navigation (2)

Re: Some minor changes to pgbench

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Some minor changes to pgbench
Date: 2006-08-23 14:09:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Tom Lane wrote:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
>> * The schema now uses foreign keys to more accurately reflect a finacial DDL
> Addition of foreign key checking will certainly impact performance
> significantly.

That is kind of the point. Without foreign keys it is a flawed test 
because you wouldn't be running in production without them and thus you 
can't bench without them.

>> * The history table now has a primary key that uses a serial
> Ditto.

Again, part of the point :)

>> * The respective balance columns have been increased to int8 to deal 
>> with larger values
> Ditto.

This was done because you can easily break pgbench without the increase 
in data type.

pgbench -c 850 -t 1000 pgbench

gave a stream of errors like this before ending:
Client 18 aborted in state 8: ERROR:  integer out of range
Client 429 aborted in state 8: ERROR:  integer out of range
Client 168 aborted in state 8: ERROR:  integer out of range

PG error log showed:

2006-08-22 15:45:19 PDT-[local]STATEMENT:  UPDATE branches SET bbalance 
= bbalance + 4209228 WHERE bid = 679;
2006-08-22 15:45:19 PDT-[local]ERROR:  integer out of range

>> * Initalization will be done in a new schema/namespace, pgbench will 
>> exit if this schema/namespace exists
> OK, maybe that doesn't matter.

Yeah I did it just so we wouldn't stomp on somebody on accident.

>> * The new DDL should allow both Mammoth Replicator and Slony to be 
>> tested using pgbench (at least basic replication)
> Erm ... exactly why couldn't you do that before?

history was missing a primary key. It could be done before. I just 
removed a step in getting it to work.

> pgbench doesn't have all that many things to recommend it, but what
> it does have is that it's been a stable testbed across quite a few
> PG releases.  Arbitrarily whacking around the tested functionality
> will destroy that continuity.

Well to be fair, I wasn't doing it arbitrarily. I had a specific purpose 
which was to have it use a schema that would be closer to a production
schema, without breaking existing behavior.

This patch does that :)

>  I fell into this trap before myself
> ... I have a local copy of pgbench that produces TPS numbers quite
> a lot better than the standard pgbench, against exactly the same
> server.  What's wrong with that picture?

Well I think we all agree that some of the behavior of pgbench has been


Joshua D. Drake

> 			regards, tom lane


    === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
    Providing the most comprehensive  PostgreSQL solutions since 1997

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2006-08-23 14:09:37
Subject: Re: Tricky bugs in concurrent index build
Previous:From: Hannu KrosingDate: 2006-08-23 14:08:34
Subject: Re: Replication

pgsql-patches by date

Next:From: Tom LaneDate: 2006-08-23 14:12:25
Subject: Re: Some minor changes to pgbench
Previous:From: Bruce MomjianDate: 2006-08-23 14:00:57
Subject: Re: [HACKERS] COPY view

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group