Thread: Sun Talks about MySQL
http://www.eweek.com/c/a/Database/Sun-Asserts-MySQL-to-Remain-Open-Source/?sp=0&kc=EWKNLINF042308STR1 i like the statement " Sun will not withhold or close-source any features that would make the MySQL community server less functional for users. " http://www.eweek.com/c/a/Database/CEO-Calls-MySQLs-the-Ferrari-of-Databases/
On Wed, 23 Apr 2008, Justin wrote: > http://www.eweek.com/c/a/Database/CEO-Calls-MySQLs-the-Ferrari-of-Databases/ I can see that, the engines from both companies make similar speed versus reliability trade-offs: http://www.f1technical.net/news/8507 -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Greg Smith wrote: > On Wed, 23 Apr 2008, Justin wrote: > >> http://www.eweek.com/c/a/Database/CEO-Calls-MySQLs-the-Ferrari-of-Databases/ >> > > I can see that, the engines from both companies make similar speed > versus reliability trade-offs: http://www.f1technical.net/news/8507 > > -- > * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD > LOL :-D
When they fail, they fail fasthttp://www.eweek.com/c/a/Database/CEO-Calls-MySQLs-the-Ferrari-of-Databases/
I can see that, the engines from both companies make similar speed versus reliability trade-offs: http://www.f1technical.net/news/8507
-- Korry
> I can see that, the engines from both companies make similar speed > versus reliability trade-offs: http://www.f1technical.net/news/8507 Guys, let's not joke about Ferrari. :) By the way, that article was immediately after the first Grand Prix of the season - a disaster for the racing team. Apparently Ferrari fixed very well the problems, as they have then won the following two grand prix. But ... Ferrari is not MySQL, guys. Actually, we already have our Ferrari in the PostgreSQL community. PhD Luca Ferrari is indeed the vice president of ITPUG. :) Ciao, Gabriele -- Gabriele Bartolini: Open source programmer and data architect Current Location: Prato, Tuscany, Italy gabriele.bartolini@gmail.com | www.gabrielebartolini.it "If I had been born ugly, you would never have heard of Pelé", George Best http://www.linkedin.com/in/gbartolini
On Wed, 23 Apr 2008 23:14:31 +0200 Gabriele Bartolini <gabriele.bartolini@gmail.com> wrote: > > I can see that, the engines from both companies make similar speed > > versus reliability trade-offs: http://www.f1technical.net/news/8507 > > Guys, let's not joke about Ferrari. :) More appropriately, don't give Ferrari a bad name by associating it with MySQL. Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
On Wed, 2008-04-23 at 16:59 -0400, korry wrote: > > > > http://www.eweek.com/c/a/Database/CEO-Calls-MySQLs-the-Ferrari-of-Databases/ > > > > I can see that, the engines from both companies make similar speed > > versus reliability trade-offs: http://www.f1technical.net/news/8507 > When they fail, they fail fast I think they have interpreted the flaws of MySQL as something they can sell more services with - so, dangerous, difficult to use etc all mean additional $$$. It's certainly what Oracle did for years. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com
On Thu, Apr 24, 2008 at 02:28:41PM +0100, Simon Riggs wrote: > I think they have interpreted the flaws of MySQL as something they can > sell more services with - so, dangerous, difficult to use etc all mean > additional $$$. It's certainly what Oracle did for years. _The UNIX Hater's Handbook_ can be interpreted as arguing that the above is also what Sun did for another well-known technology in the past ;-) A
Andrew Sullivan wrote: > On Thu, Apr 24, 2008 at 02:28:41PM +0100, Simon Riggs wrote: > > > I think they have interpreted the flaws of MySQL as something they can > > sell more services with - so, dangerous, difficult to use etc all mean > > additional $$$. It's certainly what Oracle did for years. > > _The UNIX Hater's Handbook_ can be interpreted as arguing that the above is > also what Sun did for another well-known technology in the past ;-) True, and that strategy works only when there are few alternatives. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Justin wrote: > http://www.eweek.com/c/a/Database/Sun-Asserts-MySQL-to-Remain-Open-Source/?sp=0&kc=EWKNLINF042308STR1 > > > i like the statement > " Sun will not withhold or close-source any features that would make > the MySQL community server less functional for users. " > > > http://www.eweek.com/c/a/Database/CEO-Calls-MySQLs-the-Ferrari-of-Databases/ > > The statement I like is: "This version now has zero bugs," Urlocker told eWEEK. Though that probably contributes to the immense number of new "features" . Either that, or their bugzilla installation was running on MyISAM and there was a crash... -- Chander Ganesan Open Technology Group, Inc. One Copley Parkway, Suite 210 Morrisville, NC 27560 919-463-0999/877-258-8987 http://www.otg-nc.com
On Fri, Apr 25, 2008 at 08:43:09AM -0400, Chander Ganesan wrote: > > "This version now has zero bugs," Urlocker told eWEEK. That is pretty amusing, but I also liked this: "Mickos said innovation will move even faster now that about 100 experienced database engineers from Sun will be working on MySQL development." I guess they don't read _The Mythical Man-Month_ at Sun. A
On Fri, Apr 25, 2008 at 9:01 AM, Andrew Sullivan <ajs@crankycanuck.ca> wrote: > On Fri, Apr 25, 2008 at 08:43:09AM -0400, Chander Ganesan wrote: > > > > "This version now has zero bugs," Urlocker told eWEEK. > > That is pretty amusing, but I also liked this: "Mickos said innovation will > move even faster now that about 100 experienced database engineers from Sun > will be working on MySQL development." > > I guess they don't read _The Mythical Man-Month_ at Sun. Not to rain on my MySQL/Sun bash parade, but your response is based on the extremely poor assumption that Sun would put 100 developers on a single project. While Sun has certainly had its share of software-related problems in the past, I would hope that they understand basic software project management. It's much more likely that they will have teams of 6-8 people working on individual projects. -- Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324 EnterpriseDB Corporation | fax: 732.331.1301 499 Thornall Street, 2nd Floor | jonah.harris@enterprisedb.com Edison, NJ 08837 | http://www.enterprisedb.com/
On Fri, 25 Apr 2008 10:41:24 -0400 "Jonah H. Harris" <jonah.harris@gmail.com> wrote: > > I guess they don't read _The Mythical Man-Month_ at Sun. > > Not to rain on my MySQL/Sun bash parade, but your response is based on > the extremely poor assumption that Sun would put 100 developers on a > single project. While Sun has certainly had its share of > software-related problems in the past, I would hope that they > understand basic software project management. It's much more likely > that they will have teams of 6-8 people working on individual > projects. I can only assume this response is a joke. :P Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
On Fri, Apr 25, 2008 at 10:41:24AM -0400, Jonah H. Harris wrote: > Not to rain on my MySQL/Sun bash parade, but your response is based on > the extremely poor assumption that Sun would put 100 developers on a > single project. I was certainly being a little glib, but I do think the original statement is fatuous. Adding 100 developers to a single product like MySQL -- or, for that matter, to 20 small projects all working on some feature for MySQL or even to 20 small projects all aimed at some sort of application that is supposed to work eith MySQL -- presents a pretty serious management hurdle, and one that I don't actually think can be leapt in a single bound. Therefore the claim that the sudden addition of 100 developers who know about databases to the MySQL "stable" will result in sudden increases in innovation is nonsense. It'll play to the kind of managers who believe in throwing people at a problem, of course -- and I've worked for plenty of them in my life. The claim, however, was really part of the bigger claim that the transition from small-distributed-company to organic-part-of-Sun is over: that was the real message in those comments. This, too, I find incredible. Either it's a happy face for the public, or else the honeymoon isn't over. Integrating sudden infusions of people into a strongly developed (some pronounce that "ossified") culture like Sun's takes rather more time than has passed so far, no matter how compatible the cultures seem on the surface. Power relationships do not change that fast in human societies, ever. By way of comparison, the most obviously successful absorbtion of this type Sun ever did was StarOffice, and it would be pretty hard to argue that that project was either an unmitigated victory or a fast integration. A
On Fri, 25 Apr 2008, Andrew Sullivan wrote: > Therefore the claim that the sudden addition of 100 developers who know > about databases to the MySQL "stable" will result in sudden increases in > innovation is nonsense. Adding a bunch of new developers to a project involving a code base they are unfamiliar with will inevitably reduce short-term reliability. But you can't pay attention to anything said by someone who claims any piece of software has zero bugs anyway; they've clearly lost all touch with reality and are saying nonsense. Zack at MySQL might as well have said that they have magical code fairies who have fixed 5.1 and will continue to be on board for future releases. I think it shows how much MySQL has been feeling the pain from the truly shoddy 5.0 release and its associated quality control issues that they are publicizing the incredible number of bug fixes they had to do, and flat out admitting they weren't happy with it. An interesting data point is they advertise a 10-15% gain in DBT2 results. I've started thinking about a 2008 update to my "PostgreSQL vs. MySQL" paper that covers PG 8.3 and MySQL 5.1. I'd love to have a similar comparision using that same benchmark of PG8.2->PG8.3. I recall Heikki was doing lots of tests with DBT2 for EnterpriseDB comparing those two releases like that; anybody know of a good summary I could utilize there? I thought that was one of the benchmarks that got a 20-30% speedup on going to 8.3 because it really took advantage of HOT in particular. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Greg Smith wrote: > An interesting data point is they advertise a 10-15% gain in DBT2 > results. I've started thinking about a 2008 update to my "PostgreSQL vs. > MySQL" paper that covers PG 8.3 and MySQL 5.1. I'd love to have a > similar comparision using that same benchmark of PG8.2->PG8.3. I recall > Heikki was doing lots of tests with DBT2 for EnterpriseDB comparing > those two releases like that; anybody know of a good summary I could > utilize there? I thought that was one of the benchmarks that got a > 20-30% speedup on going to 8.3 because it really took advantage of HOT > in particular. > I did some benchmarks for 8.2 and 8.3. I'll show them at PGCon in a few weeks. But I didn't try MySQL. It would be good if someone should do such a comparison. -- Euler Taveira de Oliveira http://www.timbira.com/
"Euler Taveira de Oliveira" <euler@timbira.com> writes: >> I recall Heikki was doing lots of tests with DBT2 for EnterpriseDB >> comparing those two releases like that; anybody know of a good summary I >> could utilize there? I thought that was one of the benchmarks that got a >> 20-30% speedup on going to 8.3 because it really took advantage of HOT in >> particular. If you're doing large TPC-C runs then the phantom-command-id and packed varlena changes give you about 9% space savings which translates surprisingly nicely into about 9% TPM increase. (This is for a specific schema, if you dumbify your schema with char(1)s and numerics you could see a bigger difference) HOT has a *huge* effect on how long your can run the benchmark before performance starts to droop. However the minimum run time for TPCC is only 2 hours and for large runs that's not enough for vacuum-related issues to kick in. Also, smoothed checkpoints have a *huge* effect but TPC-C is based on 95th percentile response times and the checkpoints only affect about 1% of the transaction response times. I think TPC-E will make both of these major improvements much more important. I suspect it would be hard to get 8.2 to even pass TPC-E due to the checkpoint dropouts. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning