Re: Tuning/performance issue... - Mailing list pgsql-performance
From | Oleg Lebedev |
---|---|
Subject | Re: Tuning/performance issue... |
Date | |
Msg-id | 993DBE5B4D02194382EC8DF8554A52731D7614@postoffice.waterford.org Whole thread Raw |
In response to | Tuning/performance issue... (David Griffiths <dgriffiths@boats.com>) |
Responses |
Re: Tuning/performance issue...
(Jeff <threshar@torgo.978.org>)
Re: Tuning/performance issue... (Bruce Momjian <pgman@candle.pha.pa.us>) |
List | pgsql-performance |
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@torgo.978.org] Sent: Wednesday, October 01, 2003 6:23 AM To: David Griffiths Cc: pgsql-performance@postgresql.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@jefftrout.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. *************************************
pgsql-performance by date: