In my work this week on the new test automation framework for Drizzle, I have realized that the existing MySQL test suite is in bad need of a spring (southern hemisphere) cleaning. Actually, to be clear, it's not the test runner (tests/test-run.pl and client/drizzletest.cc) which needs spring cleaning, but the tests themselves. While I have made some improvements to the runner itself, to make it more extensible and easier to understand, it is the tests themselves which represent MySQL's version of Pompeii, the Italian city buried underneath the ash of Mt. Vesuvius.

Like the bodies underneath the piles of ash in Pompeii, many of the individual tests in the MySQL test suite are frozen in time.

In a way, this is understandable, for a few reasons. …

Antony points out:

Unfortunately, I had to work with the limitations of the C programming language and its preprocessor so to achieve a solution which behaved as if it had the strong typing like generics but working with simple C;

Yeah, I started out ranting about that whole system too, but decided against it since I knew the real culprit was, as is usual, requirements. I do not envy the task of implementing C++ generics in preprocessor macros. (I do look forward to going and reading the worklog though)

As Antony suggests, I am speaking in the context of Drizzle, which means I’m speaking from the vantage point of having change the underlying assumptions. We use C++ fully in Drizzle. So whereas in MySQL this code is, as Antony says, performing properly (quite amazingly well, actually) in Drizzle …

End October - time for the traditional meeting of the German and International "PHP family" - end of October? - Yes, the International PHP Conference is a bit earlier this year. Additonally the organizers moved the conference away from the industrial area of Mörfelden to the center of Mainz which sounds quite promising. Although I'll spend only around 24hrs at Mainz I'm looking really forward to the conference next week.

On Thursday morning I'll give a presentation about PHP 5.3, which will be quite interesting as one of the biggest features, namespaces, is still undergoing heavy discussions and the final syntax probably won't be clear when presenting - fortunately PHP 5.3 is much more than namespaces!

Sun will also be present at the …

Previously on Log Buffer: Log Buffer #119.

And now.

Welcome to Log Buffer #120. My name is Warner, and I’m a SQL Server DBA at The Pythian Group. This is my first time on Log Buffer duties ever, so here’s hoping I can give everyone a fair and unbiased look at this week in the database blogging world (and related).

I admit I had no idea of the community or state of the PostgreSQL RDBMS, and so I definitely learned some new stuff this week. First off, over on “The Scale-out Blog” Robert Hodges invites us all to get our …

In response to Monty Taylor's blog post ...I am the culprit for the content of plugin.h which has the comment "the following declarations are for internal use only" which was introduced into the MySQL server codebase a couple of years ago.Unfortunately, I had to work with the limitations of the C programming language and its preprocessor so to achieve a solution which behaved as if it had the

The Data Charmer Giuseppe Maxia did some quick tests on the DTrace script and was wondering if I could optimize it a little.

One issue with the old script is that it prints every SQL statement and this can be pretty expensive. This can be minimized by printing to a file. Here is a script that will do just that. The freopen() is not documented but it opens a file and sends all prints to the file. Giuseppe reports a 30% improvement in logging performance with this improved script.

#!/usr/sbin/dtrace -qws
BEGIN
{
        freopen("/tmp/sqls");
}

pid$1::*dispatch_command*:entry
{
        printf("%d::%s\n",tid,copyinstr(arg2));
}

One more optimization that you can use with DTrace is the use of aggregates. Aggregates provides summary information. So this script will not provide you with the running log but if performance of the logger is important …

Antony points out:
Unfortunately, I had to work with the limitations of the C programming language and its preprocessor so to achieve a solution which behaved as if it had the strong typing like generics but working with simple C;

Yeah, I started out ranting about that whole system too, but decided against it since I knew the real culprit was, as is usual, requirements. I do not envy the task of implementing C++ generics in preprocessor macros. :) (I do look forward to going and reading the worklog though)

As Antony suggests, I am speaking in the context of Drizzle, which means I'm speaking from the vantage point of having change the underlying assumptions. We use C++ fully in Drizzle. So whereas in MySQL this code is, as Antony says, performing properly (quite amazingly well, actually) in Drizzle it's rather …

After a series of tests, we've just conducted the first MySQL University session using a new conferencing system, Dimdim, and I thought I'd let you know how it went.

MySQL University is an educational program for engineers from Sun/MySQL and the MySQL community, Dimdim is the new conferencing system that we hope will be able to replace our old presentation system, and "we" isn't plurale majestatis but rather refers to the guys running the MySQL University program, the Sun Database Group documentation team.

I started the Dimdim session fifteen minutes before the hour, and when the two presenters arrived we did a sound check. Petr and David connected from Sun offices in Prague, Czechia, and California, respectively, and I was on a DSL line in my home office in Berlin, Germany. Sound …

MySQL Magazine is Out and .. I wrote an aticle on it!

The magazine looks very shiny. Go get your copy.

There are a few myths surrounding the MySQL documentation and how it works, and I thought I’d try and dispel some of those myths if I can. If you have any more questions or misunderstandings you want clarified, let me know.

Myth:

MySQL Documentation is written by the developers.

Reality

MySQL Documentation is written by a dedicated team of writers with help and input from the developers. There are four main writers, Paul DuBois, Tony Bedford, Jon Stephens, and MC Brown (me!), plus our Team Lead, Stefan Hinz.

All the documentation staff are employed full time for the sole purpose of writing documentation. Sure, some of us get involved in other things too, but that’s basically the nature of the job. Some of us simply cannot help ourselves.

Myth

Docs team members are just writers and have no technical expertise.

Reality

It’s …