Re: Some minor changes to pgbench - Mailing list pgsql-patches

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/