If everything seems under control, you're just not going fast enough --Mario Andretti

The performance optimization options available are too numerous and often confusing. You need to keep the design simple by minimizing the number of optimizations required. Choosing the optimizations with biggest impacts is easy when you align them to the appropriate process in the data warehouse:

ETL performance

1. Database bulk load
2. Assuming that sufficient hardware capacity in terms of CPU processing power and disk throughput is available to support the parallelism:

• Task parallelism
• …

So, someone had a great idea to go back through the Developer Zone, which has become a bit disorganized of late, and put together an article with links and summaries for all the Dev Zone articles that discussed MySQL 5.1 features. I have done so, and also linked in many community member's blog articles and tutorials to give everyone a good dose of the features that make MySQL 5.1 worth investigating.

MySQL AB today announced a major new version of MySQL Enterprise, its commercial subscription service -- adding many new features to make it easier and more affordable for corporate database developers and DBAs to manage their high-growth Web sites and critical business applications.

In addition, the company is now featuring free-of-charge 30-day trial subscriptions for the new MySQL Enterprise service on its Web site at www.mysql.com/enterprise.

The MySQL Enterprise Fall 2007 Release was unveiled this morning at the inaugural Japanese MySQL Users Conference being held here this week in front of hundreds of MySQL users, customers, partners and employees.

MySQL AB today announced that it plans to release alpha and beta versions of several new Free and Open Source Software (FOSS) products this month, including a 'release candidate' of MySQL 5.1 -- a major new upgrade of the world?s most popular open source database server.

The announcement was made this morning at the inaugural Japanese MySQL Users Conference being held here this week.

Go see either my Flickr stream, and I’ll get things onto my Gallery as well.

MySQL is today releasing a new ODBC driver, under the version number ODBC 5.1. It is a partial rewrite of the the original MyODBC 3.51 code base, originally developed by Monty and Venu Anuganti, including individual parts of the current 65K ODBC 5 code base. It is designed to work with all MySQL versions starting with MySQL 4.1.

The original ODBC 3.51 driver was incomplete and admittedly somewhat of a quick hack, containing some debatable code. For that reason, Connector/ODBC 5 started as a complete rewrite. After 2 years it had 65 KLOC, but no tests and was in part overdesigned. That project was started but never finished, and had some deep Qt dependencies.

In the meantime, the original ODBC 3.51 has had 6 new releases and over 200 bugs fixed. As for ODBC 5.1, debatable parts of the code have been …

MySQL Proxy 0.6.0 has been tagged and should hit the mirrors near you pretty soon.

In the last 3 month of development we added a lot more features to the proxy-core which should bring the proxy closer to your needs. As always the proxy is transparent to your application, no requirement for a special language, no special needs for a platform and all customizable for your needs.

The most powerful feature is Read/Write Splitting which allows you to scale a application which is unaware of replication automaticly cross several slaves without changes to your application. Instance Scale Out we say.

The Proxy also became a 1st class citizen in the MySQL world …

Version 1.5.0 of the innotop MySQL and InnoDB monitor is out. This release is the first in the unstable 1.5.0 branch, which will eventually become the stable 1.6 branch. I'm beginning to merge the various branches I've made to support some of our needs at my employer. This first release adds some major new features and prepares for some other large improvements and new features.

As a quick follow up to the last post on malloc() speed comparisons, I decided to extend the size out a bit to cover malloc()ing up to 500M.

Time for        128k:   0.035259
Time for        256k:   0.009718
Time for        1M:     0.478129
Time for        5M:     0.968945
Time for        10M:    0.965172
Time for        50M:    0.674316
Time for        500M:   1.018901

As you can see, once you make the jump up to mmap() (>256k), the cost is fairly well constant (give or take fluctuations). So it’s not that huge memory buffers are terrible, just that there is a cost difference between the smaller and larger buffer sizes that may or may not matter in your case.

…

The recent read_buffer issue got me curious, so I hacked up a quick (ugly) test program to see if I could show the different speeds of malloc()ing different buffer sizes. Here’s the test code:

[C]
#include
#include
#include

#define LOOP 10000

int main(void) {

int x[4] = { 128,256,1024,5*1024 } ;

int f = 0;
for(f=0;f<4;f++) {
int val = x[f];

timeval before;
timeval after;

gettimeofday(&before,0);

int loop=0;
for(loop=0;loop after.tv_usec) {
udiff = (float)(after.tv_usec + 10000000 - before.tv_usec)/10000000.0;
diff = after.tv_sec - 1 - before.tv_sec;
} else {
udiff = (float)(after.tv_usec - before.tv_usec)/1000000.0;
diff = after.tv_sec - before.tv_sec;
}
printf(”Time for %dk:\t%f\n”,val,((float)diff+udiff));

}

return 0; …