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
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
Again, part of the point :)
>> * The respective balance columns have been increased to int8 to deal
>> with larger values
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 Lane||Date: 2006-08-23 14:09:37|
|Subject: Re: Tricky bugs in concurrent index build |
|Previous:||From: Hannu Krosing||Date: 2006-08-23 14:08:34|
|Subject: Re: Replication|
pgsql-patches by date
|Next:||From: Tom Lane||Date: 2006-08-23 14:12:25|
|Subject: Re: Some minor changes to pgbench |
|Previous:||From: Bruce Momjian||Date: 2006-08-23 14:00:57|
|Subject: Re: [HACKERS] COPY view|