Re: Tuning/performance issue...

Jeff,
I would really appreciate if you could send me that lengthy presentation
that you've written on pg/other dbs comparison.
Thanks.

Oleg

-----Original Message-----
From: Jeff [mailto:threshar(at)torgo(dot)978(dot)org]
Sent: Wednesday, October 01, 2003 6:23 AM
To: David Griffiths
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] Tuning/performance issue...
Importance: Low

On Tue, 30 Sep 2003, David Griffiths wrote:

>
> This is all part of a "migrate away from Oracle" project. We are
> looking at 3 databases - MySQL (InnoDB), Postgres and Matisse (object
> oriented). We have alot of queries like this
> or worse, and I'm worried that many of them would need to be
re-written. The
> developers
> know SQL, but nothing about tuning, etc.
>

There's a movement at my company to ditch several commercial db's in
favor of a free one. I'm currently the big pg fan around here and I've
actually written a rather lengthy presentation about pg features, why,
tuning, etc. but another part was some comparisons to other db's..

I decided so I wouldn't be blinding flaming mysql to give it a whirl and
loaded it up with the same dataset as pg. First thing I hit was lack of
stored procedures. But I decided to code around that, giving mysql the
benefit of the doubt. What I found was interesting.

For 1-2 concurrent
'beaters' it screamed. ultra-fast. But.. If you increase the concurrent
beaters up to say, 20 Mysql comes to a grinding halt.. Mysql and the
machine itself become fairly unresponsive. And if you do cache
unfriendly
queries it becomes even worse. On PG - no problems at all. Scaled fine
and dandy up. And with 40 concurrent beaters the machine was still
responsive. (The numbers for 20 client was 220 seconds (pg) and 650
seconds (mysql))

So that is another test to try out - Given your configuration I expect
you have lots of concurrent activity.

--
Jeff Trout <jeff(at)jefftrout(dot)com>
http://www.jefftrout.com/
http://www.stuarthamm.net/

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if
your
joining column's datatypes do not match

*************************************

This e-mail may contain privileged or confidential material intended for the named recipient only.
If you are not the named recipient, delete this message and all attachments.
Unauthorized reviewing, copying, printing, disclosing, or otherwise using information in this e-mail is prohibited.
We reserve the right to monitor e-mail sent through our network.

*************************************