I've been going through our bugs database to compile a list of some noteworthy patch contributions that have been included in the MySQL 5.5 release. Of course any contribution is appreciated, no matter how small! And the list is probably not complete — please let me know if I'm missing any. I omitted a number of smaller patches that fixed compile issues and I only considered contributions that were tracked in our bug database and were tagged as "Contribution".

Note that these are new patches that have not been part of any other MySQL release — of course, all contributions from previous releases are included in 5.5 as well. We also received a few patches for InnoDB (particularly by Mark Callaghan and his team mates at Google/Facebook), which were incorporated in the InnoDB plugin in MySQL 5.1 (and …

Everybody knows that parsing the output of SHOW ENGINE INNODB STATUS is hard, especially when you want to track the information historically, or want to aggregate any of the more dynamic sections such as the TRANSACTIONS one.

Within the InnoDB plugin the INFORMATION_SCHEMA.INNODB_TRX table was added, which allowed you to at least get some of the information on each transaction, but not the full breadth of information that SHOW ENGINE INNODB STATUS provided.

“This is nice..” I thought “..but why not go the whole hog..?”.. And so I set about doing that, and opened up Bug#53336. In a very short time, I was in a review process with the …

So after I published my patch last night, another of my colleagues - the esteemed Shane Bester - pointed out that there is a related bug - Bug#28405 - which requests that Com_change_user is also split out from Com_admin_commands.

So I extended my patch this morning, to kill two birds with one stone:

=== modified file 'sql/mysqld.cc'
--- sql/mysqld.cc       revid:alik@sun.com-20100114090008-3rsdmlp1w2mqgrhg
+++ sql/mysqld.cc       2010-03-03 09:57:40 +0000
@@ -3131,6 +3131,7 @@
   {"call_procedure",       (char*) offsetof(STATUS_VAR, com_stat[(uint) SQLCOM_CALL]), SHOW_LONG_STATUS},
   {"change_db",            (char*) offsetof(STATUS_VAR, com_stat[(uint) SQLCOM_CHANGE_DB]), SHOW_LONG_STATUS},
   {"change_master",        (char*) offsetof(STATUS_VAR, com_stat[(uint) SQLCOM_CHANGE_MASTER]), SHOW_LONG_STATUS},
+  {"change_user",          (char*) offsetof(STATUS_VAR, com_change_user), …

Kristian Nielsen presented “Beyond MySQL GA: patches, storage engines, forks, and pre-releases”.
This included a history of current products:

Google Patches (5.0 & 5.1) included improvements in :

• statistics/monitoring
• lock contention
• binlog
• malloc()
• filesorts
• innodb I/O and wait statistics
• SHOW …STATISTICS statements
• smp scalability
• I/O scalability
• semisync replication
• many more

Percona Patches (5.0) focus on

• statistics/monitoring
• performance/scalability
• buffer pool content/mutexes
• microslow patch

These have been ported to 5.1 and mainly integrated into XtraDB.

EBay Patches (5.0) have included:

• variable length memory storage engine
• pool of …

Today, the InnoDB team announced the latest release of the InnoDB Plugin, release 1.0.4. Some of the performance gains in this release are quite remarkable!

As noted in the announcement, this release contains contributions from Sun Microsystems, Google and Percona, Inc., for which we are very appreciative. This page briefly describes each of the contributions and the way we treated them. The purpose of this post is to describe the general approach the InnoDB team takes toward third party contributions.

In principle, we appreciate third party contributions. However, we simply don’t have the resources to seriously evaluate every change that someone proposes, but when we do undertake to evaluate a patch, …

After a minor coding blitz I have created 3 patches for mysqlbinlog (one is more of an enhancement of a previous patch):

• Compression support (patch here)
• SSL support (patch here)
• RAW mode (updated patch here) - See update below for updated patch
  

The compression support patch adds the --compress parameter adds support for compression when retrieving data from a remote MySQL server, much in the same way that other mysql clients do.  Basic tests indicate it compresses data up to 10x for SBR statements.

The SSL support patch adds the …

After suggestions by Sinisa on ways to improve my mysqldump progress patch I finally got around to working on these improvements.

This new patch has an extra parameter --show-progress-size which by default is set to 10,000.  So when --verbose is used, every 10,000 lines you will get a status output of the number of rows for a particular table dumped.  So what you should see is something along these lines:

shell> mysqldump -A --verbose >out.sql
-- Connecting to localhost...
-- Retrieving table structure for table testing...
-- Sending SELECT query...
-- Retrieving rows...
-- 10000 of ~94347 rows dumped for table `testing`
-- 20000 of ~94347 rows dumped for table `testing`
-- 30000 of ~94347 rows dumped for table `testing`
-- 40000 of ~94347 rows dumped for table `testing`
...

shell> mysqldump -A --show-progress-size=1500 --verbose >out.sql
-- Connecting to localhost...
-- Retrieving table structure for table testing...
-- …

Monty Taylor recently took my import progress patch and ported it into Drizzle.  I managed to spot a small bug in his conversion so took a bzr branch and fixed it.  I then spoke to Jay Pipes who suggested I could improve it by making it take a parameter which would be the number of lines per output (rather than fixed at 1000 for the original patch).

After I made the improvement I have started taking on more work for the Drizzle project in my spare time and have somehow got myself into the top 20 contributors.  But that is another story.

I have now taken my work on Drizzle …

After a discussion with Mark Leith yesterday I decided to modify my import progress patch to have an option to turn it on/off.

This new patch adds a --show-progress parameter to the MySQL client which is disabled by default.  This is because there may be utilities or scripts using the MySQL client and capturing stderr output, the original patch would create some mess in this situation.  To use the new patch you can do:

shell> mysql --show-progress < importfile.sql

Sometimes when importing data into MySQL using the following method it can take a very long time, especially if the file is very large in size:

shell> mysql < importfile.sql

I have therefore developed a tiny patch to the mysql client which uses stderr to show the progress of the import in number of lines every 1000 lines of import.  This isn't quite a progress bar but should give you an indication of how long the import will take.

The patch for MySQL 5.1.30 is available here.