This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
=== Subject: [HACKERS] A test to add to the crashme test From: Michael Robinson <robinson@netrinsics.com> Date: Mon, 22 May 2000 14:39:46 +0800 (+0800) In MySQL you can't update on a join. It's a real pain in a well-factored database. -Michael Robinson P.S. When it comes to ROLAP, though, MySQL kicks PostgreSQL's butt. For that application only, I use MySQL. === Subject: [HACKERS] rolap From: Kaare Rasmussen <kar@webline.dk> Date: Mon, 22 May 2000 09:37:04 +0200 Relational online analytical processing. A variant of OLAP systems, which have their roots in decision support systems (DSSs) and executive information systems (EISs). Why the original poster will use MySQL over PostgreSQL for this is maybe best he explains. Maybe because of the supposed speed advantage ? === Subject: Re: [HACKERS] A test to add to the crashme test From: Michael Robinson <robinson@netrinsics.com> Date: Mon, 22 May 2000 15:46:39 +0800 (+0800) Tom Lane <tgl@sss.pgh.pa.us> writes: >> P.S. When it comes to ROLAP, though, MySQL kicks PostgreSQL's butt. For that >> application only, I use MySQL. > >Er ... "ROLAP"? Expound, please. Relational On-Line Analytical Processing. As opposed to Multidimensional Online Analytical Processing (MOLAP), the other kind of OLAP. The basic principle of operation is that you put all your data in a big star (or snowflake) schema, and then pare down your "cube" by pre-aggregating various dimensions of interest into various auxillary tables. It works much better than MOLAP for big, sparse, high-dimensional data (like, for example, six months of log data from an active e-commerce/content website). MySQL is extremely well suited for it: the data is essentially "read-only" so transactions, locking, etc., are not an issue, the per-row overhead is extremely small (important when you have hundreds of millions of short records), and the speed, especially with prudent indexing and datatype selection, is scorching fast. Just don't ever put any data in it that you can't reconstruct from scratch. === Subject: Re: [HACKERS] A test to add to the crashme test From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu> Date: Mon, 22 May 2000 10:58:41 -0500 On Mon, May 22, 2000 at 03:46:39PM +0800, Michael Robinson wrote: > > MySQL is extremely well suited for it: the data is essentially "read-only" > so transactions, locking, etc., are not an issue, the per-row overhead is > extremely small (important when you have hundreds of millions of short > records), and the speed, especially with prudent indexing and datatype > selection, is scorching fast. People keep claiming that applications that are essentially "read-only" don't need transactions. I'll agree in the limit, that truly read only databases don't, but I think a lot of people might be surprised at how little writing you need before you get into trouble. Case in point: Mozilla uses a MySQL db to back up their Bugzilla bugtracking system. Very popular site, _lots_ of people reading, not a lot writing (from a developer's point of view, never enough...) The problem they've seen is that if a reader someone fires off a "stupid" query, like one that returns essentially every bug in the system, and a developer then tries to update the status of a bug, every single concurrent access to the system has to wait for the stupid query to finish. Why? Because the writer attempts to aquire an exclusive lock, and blocks, waiting for the stupid query. Everyone else blocks, waiting for the writer's lock. How many writer's does it take for this to happen? One. I'd call that an "essentially read-only" system. A note, this is not a made up, theoretical example. We're talking real world here. Ross P.S. here's the entry in bugzilla about this problem: http://bugzilla.mozilla.org/show_bug.cgi?id=27146 ===