This link adds to the joy... http://forums.mysql.com/read.php?25,93181,93181 So the most popular free "database" in the world is a lousy performing product that accepts 'gabba gabba hey' as a valid timestamp. Someone please, give me a reason not to get cynical... > -----Original Message----- > From: Matthew T. O'Connor [mailto:matthew@xxxxxxxx] > Sent: den 8 december 2006 19:35 > To: David Goodenough > Cc: pgsql-general@xxxxxxxxxxxxxx > Subject: Re: Performance figures from DbMail list > > Quick follow up on this, the guy who ran this test retested with a much > newer version of MySQL and sent this message to the DBMail mailing list > today. > > Ok, I just did the test on mysql 5.0.27. It took 73 seconds > to deliver the 1000 messages. So, it's a good bit faster > than 4.1.20's 95 seconds, but still pales in comparison to > postgres' 9 seconds. Mysql was still peaking both cpu cores > during delivery. > > > On Thu, 07 Dec 2006 11:23:58 -0800 > Michael Dean <mdean@xxxxxxxxxxxxxx> wrote: > >> > > Lars Kneschke wrote: > >>> > >> Justin McAleer <justin@xxxxxxxxx> schrieb: > > > I think a test of 5.0 and 8.2 would be great! Recent > > > benchmarks of the > > > two show pg really blows the socks off mysql, so a > > > confirmation of that in the email segmnent would be > > > terrific!!! > > > Michael > > > _______________________________________________ > > > DBmail mailing list > > > DBmail@xxxxxxxxxx > > > https://mailman.fastxs.nl/mailman/listinfo/dbmail > > > > > _______________________________________________ > DBmail mailing list > DBmail@xxxxxxxxxx > https://mailman.fastxs.nl/mailman/listinfo/dbmail > > > > David Goodenough wrote: > > The following appeared this afternoon on the DbMail list. As someone > > replied the MySql used is old, and the newer one is faster, but then > > 8.2 is faster than the older Postgresql versions. > > > > This was posted by:- "Justin McAleer" <justin@xxxxxxxxx> > > > > I figured I would go ahead and toss this out for anybody > > that may be interested, since I was so shocked by the > > results. I have two servers set up for testing, one running > > postfix/dbmail and one running the database servers. The > > database machine is a dual core AMD (4400+ I believe) with > > 4 gigs of memory, with the database files living on a fiber > > connected Apple SAN (XRaid). I have dbmail compiled with > > mysql and pgsql, so all I need to do to switch between the > > two is change the driver in the conf file and restart. I'm > > using dbmail-lmtpd running on a unix socket. Finally, I > > have the postfix delivery concurrency set to 5. > > > > For mysql, I'm using a 4GB InnoDB sample config that comes > > in the CentOS rpm (increased the buffer pool to 2.5 gigs > > though). Version is 4.1.20. > > > > For postgres, I'm using the default variables except for > > increasing the shared buffers to 256MB, setting effective > > cache size to 3 GB, and random page cost to 2. Version is > > 8.1.4. > > > > I've sent a good amount of real mail to each setup as well, > > but for quantifiable results I have a perl script that > > sends gibberish of a configurable size (3kb here) to a > > single recipient. Since we're inserting into a DB, the > > recipient of the messages should have no bearing on > > delivery performance, barring postfix concurrency. > > > > For the test, I sent one batch of mail through so postfix > > would already have a full lmtp connection pool when I began > > the real test. I had 10 perl processes each sending 100 > > messages as fast as postfix would accept them, for a total > > of 1000 3KB messages. Results... > > > > Mysql: 95 seconds to deliver all 1000 messages. Both cores > > on the DB server were effectively peaked during delivery. > > > > Postgres: 10 seconds to deliver all 1000 messages. DBMail > > was really close to being able to deliver as fast as > > postfix could queue to local disk (within a second or two > > for 1000th message). The cores on the DB server looked to > > average around 45%/30% usage during delivery. > > > > The CPU usage is just based on watching top output, so keep > > that in mind... however with such a huge variance, even > > eyeballing it I'm confident in reporting it. > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 1: if posting/reading through Usenet, please send an appropriate > > subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your > > message can get through to the mailing list cleanly > > > > -- > Matthew T. O'Connor > V.P. Operations > Terrie O'Connor Realtors > 201-934-4900
