Re: Tuning/performance issue...
От | Bruce Momjian |
---|---|
Тема | Re: Tuning/performance issue... |
Дата | |
Msg-id | 200310040139.h941deb01679@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Tuning/performance issue... (Oleg Lebedev <oleg.lebedev@waterford.org>) |
Ответы |
Re: Tuning/performance issue...
(Rod Taylor <rbt@rbt.ca>)
Re: Tuning/performance issue... (Jeff <threshar@torgo.978.org>) |
Список | pgsql-performance |
I have updated the FAQ to be: In comparison to MySQL or leaner database systems, we are faster for multiple users, complex queries, and a read/write query load. MySQL is faster for SELECT queries done by a few users. Is this accurate? It seems so. --------------------------------------------------------------------------- Oleg Lebedev wrote: > 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. > > ************************************* > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-performance по дате отправления: