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 …

The following comment:

/* the following declarations are for internal use only */

is about 35% of the way down drizzled/plugin.h. How about:

If it’s for internal use only - DONT PUT IT IN A HEADER FILE!!!!!!!!! At least not a header file that’s used by things.

In particular, what is notably absent from the proposals, is contribution from other Sun communities. Java, Glassfish, Netbeans, Solaris, OpenOffice, are either completely amiss or faintly represented. We need good technical presentations on the above topics, involving MySQL usage and integration. And remember, the theme of the conference is …

I'm trying to learn more about Zmanda and MySQL.  It's just ones of those topics that is on my list of things to Google.  At this point, I know that Zmanda can do backup and recovery for MySQL, but that is about it. I'd really like to get a better grasp of the technology and how it benefits a MySQL user.  Interestingly enough, over the past week or so, I've found a few mentions of Zmanda in my inbox that might speed this learning process along.  So, I thought that I would share them with those people who find themselves in the same situation. 

• Whitepaper: Zmanda Recovery Manager
• Webinar: The Essentials of MySQL Backup & Recovery : Zmanda Recovery Manager (ZRM) for MySQL on Thursday, November 06, 2008, 16:00 GMT, 17:00 CET …