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: | 44EC6181.6000601@commandprompt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-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
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/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-08-23 14:09:37 | Re: Tricky bugs in concurrent index build |
Previous Message | Hannu Krosing | 2006-08-23 14:08:34 | Re: Replication |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-08-23 14:12:25 | Re: Some minor changes to pgbench |
Previous Message | Bruce Momjian | 2006-08-23 14:00:57 | Re: [HACKERS] COPY view |