On Friday 01 February 2002 14:39, Matt Sergeant wrote: > On Fri, 1 Feb 2002, Tod Harter wrote: > > Its only a myth until you run benchmarks on real-world applications. As > > the guy said, its not an end-all and be-all of databases by any means. On > > the other hand its generally a LOT faster than serializing stuff to cache > > it, and simple enough to run that it probably is a viable alternative in > > cases like this. Even if you use pg or Oracle or whatever you could cache > > commonly used data sets to a faster server. If you need sub-selects, > > cascading deletes/foreign keys, or triggers, or stored procedures, then > > use something else. PG is a fine database, but it can be a LOT slower, > > and it is definitely harder to manage. MySQL servers can take a major > > pounding and stay up for months at a time with zero maintenance. > > Sometimes simplicity is a virtue ;o). > > [This is totally off topic, but it's my server so what the hell ;-)] > > That's the opposite of my experience, is all I can say. Under load MySQL > becomes flaky as anything. It's thread management sucks, its query > optimisation sucks, and when it goes down, it goes down hard. > > Pg on the other hand has been nothing but sweet to me. Stable, fast, > reliable, and easy as pie to setup. And much easier to manage data in > there because you can use views and triggers and referential integrity. > Now I *know* MySQL is getting all these things. It's been slowly getting > them for years now. But I'd rather use something that works today (which > is why I'm not willing to wait for Microsoft to retro fit security and > stability onto their platforms), and that for me is Pg.
I think it depends heavily on the task at hand. Threading issues has to do with pthreads (at least on Linux) for which you need to do a patch to correct some really DUMB defaults that are present there. I'd consider that fairly routine performance tuning stuff. Its query optimization is excellent, its just the queue management that can be problematic (as the other guy stated) which again you can mitigate by telling MySQL to give certain queries precedence. Personally I've never had it go down under any circumstances on a production system. The features you mention are nice things to have, even mandatory in some applications, but if you don't need them they drag down performance to no end. I stand by this, for relatively straightforward schemas where you have heavy read access and most queries are fairly similar in complexity its really fast and runs like a champ. Doesn't mean I'd use it to do everything. pg works really well for the things its suited for as well. I think its a case of using "the best tool for the job". I'll throw in one other plus to MySQL though. Its very secure. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
