Thread: Another "benchmark" of MySQL/PostgreSQL on MySQL maillist
Hi! Here it is: http://lists.mysql.com/list.php?1:mss:145114:mbnfmalgopgpdmpooeho I already asked the author whether he tried to reasonably tune PostgreSQL before benchmarking. It will be good if some "official" PostgreSQL folks help with the discussion. I think that if the author of the "benchmark" really wants to get decent performance (and not to bash Postgres) then he will re-run the stuff. And that's a good possibility to show MySQL users the real performance situation --- and in their own maillist. ;
On 15 Jul 2003 at 13:29, Alexey Borzov wrote: > Hi! > > Here it is: > http://lists.mysql.com/list.php?1:mss:145114:mbnfmalgopgpdmpooeho > > I already asked the author whether he tried to reasonably tune > PostgreSQL before benchmarking. It will be good if some "official" > PostgreSQL folks help with the discussion. Well, yes. Ask him to come over to performance list, if he cares. I doubt that looking at the entire thread. Only couple of sensible postings with a benchmark page at http://www.sergeant.org/sqlite_vs_pgsync.html for which I couldn't find postgresql.conf file. Furthermore sqllite results do not agree with http://www.sqlite.org/speed.html in themselves.. > I think that if the author of the "benchmark" really wants to get decent > performance (and not to bash Postgres) then he will re-run the stuff. > And that's a good possibility to show MySQL users the real performance > situation --- and in their own maillist. ; I won't be too optimistic about that. But worth a try.. Bye Shridhar -- bit, n: A unit of measure applied to color. Twenty-four-bit color refers to expensive $3 color as opposed to the cheaper 25 cent, or two-bit, color that use to be available a few years ago.
On Tue, 2003-07-15 at 05:55, Shridhar Daithankar wrote: > On 15 Jul 2003 at 13:29, Alexey Borzov wrote: > > > Hi! > > > > Here it is: > > http://lists.mysql.com/list.php?1:mss:145114:mbnfmalgopgpdmpooeho > > > > I already asked the author whether he tried to reasonably tune > > PostgreSQL before benchmarking. It will be good if some "official" > > PostgreSQL folks help with the discussion. > > Well, yes. Ask him to come over to performance list, if he cares. I doubt that > looking at the entire thread. Only couple of sensible postings with a benchmark > page at http://www.sergeant.org/sqlite_vs_pgsync.html for which I couldn't find > postgresql.conf file. Furthermore sqllite results do not agree with > http://www.sqlite.org/speed.html in themselves.. > Actually that page is interesting as much for the things it leaves out. It compares pgsql and sql lite in a async mode and fsync mode. It gives some explanation on why the fsync mode is so much slower for sql lit, but it seems to overlook that postgresql also can turn fsync on or off (the default is on, which would slow postgresql down). Also I noticed that these test were run against postgresql 7.1.3, which is a bit outdated. Even tuned you'd have to expect it to perform slower than 7.3.3. The other thing there seems to be no mention of is whether there were ever any vacuum/analyze performed. In some of these tests that would be a pretty important factor (like between the two 25,000 update tests) > > I think that if the author of the "benchmark" really wants to get decent > > performance (and not to bash Postgres) then he will re-run the stuff. > > And that's a good possibility to show MySQL users the real performance > > situation --- and in their own maillist. ; > > I won't be too optimistic about that. But worth a try.. > It's worth noting that the original poster was not the sqlite benchmark guy. Since the sqlite test is publicly available, I think you could run it against a more recent, tuned version and the author probably would accept it. In the end though I'd expect sqlite to be faster, it has a narrow feature set and specific scope, and we probably can't scale down to that level. (For sure we scale up higher, but that's not whats being measured. As for the original poster, unless he shows up on -performance I think his mind is already made up. Robert Treat -- Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Hi! Robert Treat wrote: > It's worth noting that the original poster was not the sqlite benchmark > guy. Since the sqlite test is publicly available, I think you could run > it against a more recent, tuned version and the author probably would > accept it. In the end though I'd expect sqlite to be faster, it has a > narrow feature set and specific scope, and we probably can't scale down > to that level. I don't think it's a good idea to try to compete with SQLite... Due to its limitations (locking the whole file representing a database on INSERT/UPDATE) it will go belly-up quite fast in the case of concurrent write access. The reason I posted the link for this benchmark to MySQL maillist is not because I am perfectly happy with it, but because it clearly shows the difference between default and tuned PostgreSQL and claims that tuned PostgreSQL is as fast as MySQL with MyISAM (the original poster was using InnoDB, which is most probably slower) > (For sure we scale up higher, but that's not whats being > measured. As for the original poster, unless he shows up on > -performance I think his mind is already made up. Yes, the guy does sound like a cheerleader. Let's see if he answers anything...
On Tue, 15 Jul 2003, Alexey Borzov wrote: > Hi! > > Here it is: > http://lists.mysql.com/list.php?1:mss:145114:mbnfmalgopgpdmpooeho > > I already asked the author whether he tried to reasonably tune > PostgreSQL before benchmarking. It will be good if some "official" > PostgreSQL folks help with the discussion. > > I think that if the author of the "benchmark" really wants to get decent > performance (and not to bash Postgres) then he will re-run the stuff. > And that's a good possibility to show MySQL users the real performance > situation --- and in their own maillist. ; Invariably, what's happened is they've written code full of select max(id) from table_of_a_million_records or select * from table where id in (list_of_1000_ids) or they are trying to insert 10,000 rows but not bothering to put them in a transaction. Add to that the fact that 99% of these folks have NOT bothered to optimize the postgresql.conf file or the OS they're running on and it just gets worse. Most of the time, it's a simple case of not taking to time to learn the way to do things fast in the newer database. the funny thing is, as MySQL adds these features, it WILL slow down. then the users who wanted triggers / views etc... will find themselves with the same problems in MySQL they are complaining about in Postgresql. I.e. they'll have to learn the workarounds to make things faster. As an engineer, I value stability and reliability first, since MySQL seems to be missing those qualities, it's not even in the running for me.
On Tue, 15 Jul 2003, Shridhar Daithankar wrote: > Well, yes. Ask him to come over to performance list, Did he get an invitation by anyone? To ask him and tell him that we would like to know more about his problem would hopefuly be enought. Then we can either help him fix the speed issue or at least understand why it is slow in pg. He should be interested in that (I hope). -- /Dennis