Re: Great Bridge re-runs benchmark with MySQL "tuned" - Mailing list pgsql-general

From Ned Lilly
Subject Re: Great Bridge re-runs benchmark with MySQL "tuned"
Date
Msg-id 39A2D024.FD4D05DB@greatbridge.com
Whole thread Raw
In response to Great Bridge re-runs benchmark with MySQL "tuned"  (Ned Lilly <ned@greatbridge.com>)
List pgsql-general
See http://www.greatbridge.com/news/p_081620001.html - we increased the
cache, ran a vacuum analyze, a few minor things.

Regards,
Ned

"Poul L. Christiansen" wrote:

> It would be interesting to see how well PostgreSQL performed when it was
> tuned.
>
> Or has it allready been tuned?
>
> Ned Lilly wrote:
>
> > Folks,
> >
> > We posted the following announcement on our website today, at
> > http://www.greatbridge.com/news/press.html.
> >
> > Please feel free to email me off-list with any questions.
> >
> > Thanks,
> > Ned
> >
> > UPDATE, August 22, 2000:
> >
> > MySQL performance improves with tuning suggestions from development
> > team;
> > PostgreSQL still leads all contenders under heavy usage
> >
> > Following our recent release of AS3AP and TPC-C benchmark test
> > results, Great Bridge offered to re-run the tests with tuning and
> > custom configuration settings suggested by the MySQL development
> > team. We did, and we want to share the results.
> >
> > It's important to note that the MySQL configuration originally
> > tested was the default MySQL installation, using the standard
> > MyODBC.dll Windows driver installed by MySQL (for the benchmark
> > software client machine, which ran Windows NT). Probably the most
> > significant change came from substituting a faster driver, called
> > MyODBC2.dll; according to the MySQL development team, the default
> > driver is used for debugging purposes, and is known to be slower in
> > production environments.
> >
> > At their suggestion, we also implemented the following tuning
> > settings:
> >
> > * key_buffer=64m
> > * table_cache=256
> > * sort_buffer=1m
> > * record_buffer=1m
> >
> > So what were the results? MySQL did significantly better across the
> > board, averaging 69% more transactions per second in this tuned
> > environment, and exceeding Postgres' raw performance until the
> > seventh concurrent user. Its performance peaked at 1,321 tps (at 3
> > users), but still started to fall off about the same point as in the
> > previous test (4 users). See graphic
> > (http://www.greatbridge.com/img/as3ap_new.gif).
> >
> > What does this mean? Our interpretation is that, properly
> > configured, MySQL is indeed a faster performer in raw read-only
> > databases with 6 or fewer users. We should note that these tests
> > results do not represent the full suite of AS3AP tests - only the
> > multiuser ir_select (information retrieval) test. Other tests in the
> > AS3AP suite require views, which MySQL does not currently support.
> > We should also note that the TPC-C test, which simulates a more
> > robust OLTP environment, still would not run under the tuned MySQL
> > configuration, primarily due to SQL compliance issues (see Richard
> > Brosnahan's analysis elsewhere in the main story). But overall,
> > MySQL acquitted itself well when expertly tuned for the AS3AP
> > ir_select test.


pgsql-general by date:

Previous
From: "Jeffrey A. Rhines"
Date:
Subject: Re: [Solved] SQL Server to PostgreSQL
Next
From: Stephan Szabo
Date:
Subject: Re: Foreign key to all inherited tables