I've wondered and am still wondering what a lot of these benchmark tests
are out to prove. I'm not sure that any PostgreSQL advocate has ever said or
implied that PostgreSQL is faster than anything, much less MySQL. While I'm
sure it's faster than some, I've just never heard the argument for using
PostgreSQL as "It's faster than anything else". I chose PostgreSQL by what
it could do, not how fast it can SELECT... No benchmark between MySQL and
PostgreSQL (or any other RDBMS ) is ever going to be truly accurate since
there are so many things MySQL simply can't to that PostgreSQL (and others)
can..
As Don often out often and accurately points out, MySQL is not an RDBMS,
I'm not sure what it really is beyond a semi-fancy SQL interface to a file
system.. Is it fast? Yes, it is pretty fast. Fast at the expense of
functionality and stability -- two things that just aren't optional when
you're talking about a good database for anything more complicated than
click-through tracking...
I don't dislike MySQL for any other reason except that it can't do what
I need it to do, period... I'm sure it's good for some things and some
people, I've tried MySQL, tested MySQL and then tossed MySQL into the
garbage can...
I found some very educational conversation here :
http://openacs.org/philosophy/why-not-mysql.html courtesy of Don and others.
-Mitch
----- Original Message -----
From: "Don Baccus" <[EMAIL PROTECTED]>
To: "Robert D. Nelson" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
"Michael Fork" <[EMAIL PROTECTED]>; "Poul L.Christiansen"
<[EMAIL PROTECTED]>
Cc: "pgsql-general" <[EMAIL PROTECTED]>; "pgsql-hackers"
<[EMAIL PROTECTED]>
Sent: Monday, November 20, 2000 8:48 PM
Subject: Re: [HACKERS] RE: [GENERAL] PHPBuilder article -- Postgres vs MySQL
> At 11:22 AM 11/13/00 -0500, Robert D. Nelson wrote:
>
> >Still...Regardless of what database they're running, either their
> >abstraction layer is shit or their queries really need optimized. Is that
> >perhaps why, even at 5 clients, the page views he shows never went
> >significantly above 10/sec?
>
> They don't appear to do any client-side query caching, which is
understandable
> from one point of view (you need some sort of handle on which queries are
> hit frequently enough to warrant devoting RAM to caching the result, or
else
> you risk caching things that don't gain you much and cut down on the
amount
> of the DB cached in RAM which hits you on other queries). On the other
hand,
> you'd think they'd do some analysis...
>
> Still, the table-locking of MySQL just gets in the way. If you can cache
> everything, then you can send a postal worker to the mailbox to retrieve
> uncached data without significantly impacting throughput (in other words,
> the MySQL argument that simple select benchmarks are all you need are
> not relevant). If you can't cache anything but have few users, then
perhaps
> low levels of concurrency don't hurt. If you don't cache anything but
have
> lots of users, scaling well under high levels of load rule.
>
> My thinking is that intellegent caching coupled with a highly-scalable
> database wins. That's the world I'm used to...
>
>
>
> - Don Baccus, Portland OR <[EMAIL PROTECTED]>
> Nature photos, on-line guides, Pacific Northwest
> Rare Bird Alert Service and other goodies at
> http://donb.photo.net.
>