Comments on: Interesting MySQL and PostgreSQL Benchmarks

By: 旋转木马の阶梯 » Blog Archive » links for 2007-09-18

旋转木马の阶梯 » Blog Archive » links for 2007-09-18 — Tue, 18 Sep 2007 02:24:15 +0000

[...] Interesting MySQL and PostgreSQL Benchmarks From MySQL performance blog. (tags: mysql performance postgresql) [...]

By: Senthil

Senthil — Tue, 26 Jun 2007 14:00:45 +0000

Do you have any numbers on Mysql(MYISAM) vs Postgresql?

By: Debunking MySQL vs PostgreSQL performance myths at Alex Mayrhofer

Debunking MySQL vs PostgreSQL performance myths at Alex Mayrhofer — Sat, 05 May 2007 17:54:03 +0000

[...] i lost tons rows in MySQL databases for no reason (admitted, that was version 3.23.something), this article (which in turn cites this test) did definitely put a dirty grin on my [...]

By: Aria Kokoschka

Aria Kokoschka — Tue, 23 Jan 2007 20:04:06 +0000

Solaris has a well-designed and matured threading library as opposed to Linux. Maybe that’s one of the reasons for its performance benchmark.

By: MySQL Performance Blog » MySQL/Innodb scalability tests after fix

MySQL Performance Blog » MySQL/Innodb scalability tests after fix — Wed, 03 Jan 2007 11:12:07 +0000

[...] I already wrote about interesting benchmarks Tweakers.net have done for MySQL and PostgreSQL with different CPUs. I was in contact with Tweakers.net team to see if they miss something obvious in MySQL settings as well as to let them know the fix is now out for Innodb scalability bug and they can rerun the test to see if there are any difference. [...]

By: Doomshammer's Weblog

Doomshammer's Weblog — Sat, 30 Dec 2006 16:55:33 +0000

MySQL vs. PostgreSQL benchmarks…

I found an interessting article at the MySQL Performance blog, pointing me to these benchmarks:MySQL vs. PostgreSQLRDBMS on Solaris vs. LinuxIt’s pretty interessting to see, that PostgreSQL is performing very well, where MySQL is suffering very quickl…

By: James Day

James Day — Sat, 09 Dec 2006 07:23:28 +0000

Kees, re sort_buffer_size, see http://bugs.mysql.com/bug.php?id=21727 for a particularly unpleasant case that explains what may have been happening. You may find that the fix for that improves things if you are sorting in subqueries. You’ll need to get it from BK since it’s not yet in any release. Since you can adjust the sort_buffer_size for each query if you want to tune things you could consider that, though it’s going a bit further than most people would go.

It would be good if you said more about your software configuration. For example, Peter wrote that you’re using InnoDB but I normally assume MyISAM and not knowing which engine(s) are in use can make it hard to know what the results mean, if anything. Your comment does seem to say that you’re using InnoDB.

By: peter

peter — Wed, 06 Dec 2006 09:00:00 +0000

Alexey,

It actually depends. Sort buffer can be allocated while only couple of rows can be sorted. The slowdown can be very well seen with subqueries which use order by where millions of sorts would happen.

Regarding sort and cache fit this would only apply to rather large data sets – if sort set fits in 1MB and 2MB of sort buffer is allocated still only small portion of it would be touched. If data is in 1MB-2MB range you would have disk based sort if your sort buffer was just 1MB which is likely worse than few key misses.

Two more reasons why I think this is not just cache is how QuickSort works – most of the operations are done local to the small blocks, and only last pass would traverse all data set and the fact it is mention to only apply to Solaris, not other operation systems.

But I can be wrong about guess about mmap() in this particular case – it could be something else. Profiling could show.

By: Alexey

Alexey — Tue, 05 Dec 2006 23:28:56 +0000

I think this explanation is wrong. mmap() call takes only a few microseconds, it’s insignificant comparing to time spent in sorting.
IMO the real reason is cache miss ratio. If a sort window doesn’t fit your cache, a lot of key swapping operations result in cache misses. If it does, you sort a chunk of data really quick, then drop it into main memory (tmp table which isn’t neccessarily written out to disk), and after all chunks are sorted, do a single pass scan.

By: peter

peter — Mon, 04 Dec 2006 17:13:59 +0000

Thanks,

Yes I can see why changing sort_buffer can give such effect. Larger allocation can be allocated via mmap() rather than by standard memory allocator which may be relatively expensive as it requires OS syscall plus page table modifications.