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:[EMAIL PROTECTED] 
> Sent: Wednesday, October 01, 2003 6:23 AM
> To: David Griffiths
> Cc: [EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]>
> 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
  [EMAIL PROTECTED]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to [EMAIL PROTECTED] so that your
      message can get through to the mailing list cleanly

Reply via email to