Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> 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
weird.
Sincerely,
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
http://www.commandprompt.com/
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
