Re: Tuning/performance issue...

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(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.
>
> *************************************
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073