In the current API when sending one takes the Transporter mutex and
then sends all the signals generated towards one or many nodes.
There is also some handling of adaptive sends, however this adaptive
algorithm takes care of all nodes, thus waiting for sending is global
on all nodes.

The new design uses one mutex for the sending, however this mutex only
controls the sending part of one socket. Also the time for holding the
mutex is just enough to check the state, no send operations are done
while holding the mutex.

The new adaptive algorithm will keep track of the last sent messages on
this socket and in principle the idea is that if it's at least a 90-99%
probability that it is a good idea to wait, then it will wait (unless
the application has provided the force send flag). It will do so by
keeping track of the last few messages sent. …

Kickfire is one of the coolest open-source (based) companies to launch within the last few years. Today, it announced that it has raised $20 million in series B funding to tell the world about what it's doing.

What does Kickfire do? From a business angle, it has figured out ...

Just a few short years ago, there was one open-source hosting service worth considering: Sourceforge.net. It was by no means perfect (Alfresco's analytics, for example, have been down for over a month on Sourceforge, with no apparent urgency to fix the problem), but it was good enough, free, and everyone else used it.

Today, there are multiple options, including Google Code, Microsoft CodePlex, CodeHaus, GitHub, and, interestingly, Canonical's Launchpad.

Yes, Launchpad. Launchpad is the brainchild of Mark Shuttleworth's Ubuntu team, but it has aspirations beyond hosting the Ubuntu code, aspirations that recently attracted MySQL to move its code over to the Launchpad service.

I don't recall Launchpad …

I was there in the meetup and my feeling was a mix about the same. It was nice to have Kaj here (for the first time) and listen to him about Sun's acquisition. On the other hand it was disheartening to see so few people from corporates turning up. It was almost negligible. I'm still positive on this and do expect many more people to turn up. There were a total of three talks in the meet and then we had some chit chat with people.

In his first talk, Kaj first greeted everybody in Hindi, Tamil and Kannada and many were delighted. Kaj touched various aspects of Sun's acquisition and also their on-boarding struggle. He also mentioned about MySQL considering Sun's liberal SCA in place of their stricter CLA. (I haven't gone through SCA to actually comment on it's benefits)

Second talk by Thava was on how to contribute code to …

Some time ago, with the help of Patrick Crews, I built a sample database for testing.
Now this database is published as a stand-alone project on Launchpad.

What's special about it?
Unlike the previous databases used in MySQL documentation and tutorials, this database has some weight. The total data is over 160 MB, distributed across 6 table, for a total of about 4 million records. It is not huge, but it is large enough to be non-trivial.
The second important feature is that this database comes with a test suite. This will allow you to make sure that you have loaded the right data.
Getting startedUsing the sample database is trivial.
Open the test db downloads page and get the current …

This MySQL event with Kaj Arno was well received. Kaj talked about the product, from different aspects, both technical and business with bit of short history, how the community could contribute, how safe MySQL at the hands of Sun, etc. It was very engaging and informative.

In his typical style of localising presentations beyond english , he started the presentations with speaking couple of sentences in few local languages: Kannada, Tamil and Hindi. The audiences were pleasantly surprised and this received huge applause.

I talked about specifically how to contribute code to MySQL-- how to get started with a focus to contribute code. I put lots of urls through out the presentation and I promised to make the slides available through my blog. Here is the slides uploaded to slideshare.net :

…

At the MySQL User's conference 2008 I did a tutorial on MySQL User-defined functions. At the same conference, Brian Miezejewski and Mark Atwood did a talk on aggregate UDFs.

In relation their upcoming talk, Mark wrote a blog post reporting that MySQL Aggregate UDFs are three times slower than equivalent native functions:I just proved to myself via testing and benchmarking that user defined aggregate functions are about three times slower than the call interface to the built-in functions.Later on he posted an update, …

I am often asked why we chose a distributed, web-based architecture for the Enterprise Monitor application. For those not familiar with how the app is deployed, the Enterprise Monitor is typically installed within a customer firewall and is comprised of 3 components:

- a lightweight agent written in C, that is deployed to each monitored server to collect MySQL, OS data and Query content and diagnostics
- a centralized server that monitors the collected data and queries, sends out alerts and serves up the supporting web application
- a MySQL repository that holds the collected data and queries

A typical deployment looks something like this:



Having come to MySQL from Embarcadero Technologies, I …

An event truly fitting an “open world” — I will be speaking at Oracle Open World.

How does a wild-mannered MySQL DBA like me get to speak at an Oracle conference? Well, after I received the MySQL Community Award two years in a row, Dan Norris contacted me, and encouraged me to submit a proposal with him on how to contribute to the community.

Oracle has a formal program for recognizing community members at two levels: the Oracle ACE Director, and the Oracle ACE. An Oracle ACE Director is expected to make a 12-month commitment to working with the community, while an Oracle ACE is bestowed upon folks to recognize their volunteer efforts in the past. More information about the program can be found on …

I spent some time during my vacation thinking about some
new ideas. I designed the first version of the NDB API
about 10 years ago and obviously in those days the maximum
number of CPU's in most systems was 2 so it wasn't a big
problem having a single mutex protecting send and receive
in the NDB API (The NDB API is the low level API used by the
storage engine NDB which is the storage engine in MySQL
Cluster).

Another design criteria I made when designing the NDB API
was that most developers want to use a synchronous API.
Thus the asynchronous API was made afterwards and didn't
cover all operations. Most developers still develop using
synchronous API's, however most of the use for the NDB
API is for specialised applications such as Telco servers,
storage engine code, LDAP servers. Also I'm thinking in
even using it inside an operating system kernel to …