The merits of the open source distribution model in generating sales leads have been well documented but it’s always good to see statistics that back up the theory. I recently talked with a new open source software vendor (who will remain nameless, although in the interests of avoiding confusion I should state it was not LoopFuse) that shared with me some statistics about its first year distributing open source code and the comparative cost of lead generation using the proprietary model.

In its first year using an open source distribution model the company saw:

• A 12X increase in ‘awareness’ (web hits, community engagement, media mentions, conference visits etc).
• A 13X increase in web site visits.
• A 17X increase in software trials.
• A 40X increase in qualified …

Some time ago I have shown that the proxy can do connection pooling and can keep server-side connections open to be reused by another client later. The keepalive tutorial shows how this can be implemented.

When it comes to reusing a server-connection for multiple client connections we have to face a small problem:

SQL connections aren't stateless (temporary tables, session variables, ...)

We have to handle this somehow.

When you use this feature the proxy will clean up for you by default, by issuing a COM_CHANGE_USER as the first command that is sent to the server. It basicly resets the connection and re-authenticates the user. You always get a clean environment and can't really tell that the server-side connection was open all the time.

But you don't really win performance either. A small benchmark shall give you an idea.

# connecting the client to the server …

It's getting closer.
On Tuesday late morning, I will hold a session on MySQL Proxy during the MySQL MiniConf at Linux Conf Australia.
It will be an introduction to MySQL Proxy with some live demo.
If you are in Melbourne, come along!

Greetings from the Southern Hemisphere.
The World tour proceeds as planned, although with some added tasks in the meantime. The solution to the quiz announced from North America is now given from Australia. (Boy! I love the global village!)

The task was to create a series of three triggers, all associated to the same table for the same event (BEFORE INSERT). If you had a look at the manual, you would know that you can't set multiple triggers for the same event. However, there is a workaround, using the Federated engine. The solution to the quiz was already available as a comment to a bug report. My intended solution, very similar to the one provided by the …

Normally, I don't do rants. But now I feel compelled to debunk the - IMO - downright slanderous post entitled "14 reasons not to use MySQL or other mid-range database management systems" by Curt Monash - an otherwise seemingly un-offensive blogger.

Anyway - here's my maybe somewhat emotional analysis. But really, this post is a load of cr*p! I mean, more than half of the "reasons" are not even about MySQL (as in the database - not the company), and the other aren't even reasons.

Judge yourself.

Many enterprises get quantity discounts. License and in some case even maintenance fees may not be bad at all.

You make it seem like this is an advantage! With MySQL, *everybody* gets a volume discount. We don't care if you're big or small, if you need many MySQL servers …

So you have created your standby database using the RMAN DUPLICATE command, you have set the ARCHIVE_LAG_TARGET to maintain a minimum lag target, and you have sorted out those nasty datafile missing errors using automatic file management. You’ve even added standby redo logs to improve the Mean Time To Recovery (MTTR). Now management are demanding [...]

In about a week, I get to travel 30 hours to attend a wedding in the middle of Nowheresville, Australia (near Toowoomba). While I'm there, I've volunteered to speak at the MySQL Meetup in Brisbane. I've heard others say that "Australians are a pretty tough audience to please", and I tend to agree; there's a certain bluntness to the way we deliver questions. I think I'll have to listen to some Eye of the Tiger to warm up for it.

I’ll be attending the 2008 MySQL Conference and Expo again this year, and I’m looking forward to hearing some great sessions, meeting new and old friends, and giving sessions myself. As a proposal reviewer, I looked at and voted on 250+ proposals for sessions and tutorials for this conference. There are going to be some great sessions and tutorials.[1] If you haven’t come to the conference previously, it’s well worth your time and money, in my opinion.

Some time ago I have shown that the proxy can do connection pooling and can keep server-side connections open to be reused by another client later. The keepalive tutorial shows how this can be implemented.

When it comes to reusing a server-connection for multiple client connections we have to face a small problem:

SQL connections aren't stateless (temporary tables, session variables, ...)

We have to handle this somehow.

When you use this feature the proxy will clean up for you by default, by issuing a COM_CHANGE_USER as the first command that is sent to the server. It basicly resets the connection and re-authenticates the user. You always get a clean environment and can't really tell that the server-side connection was open all the time.

But you don't really win performance either. A small benchmark shall give you an idea.

# connecting the client to the server ...
11:58:41.241956 …

Really often in customers' application we can see a huge tables with varchar/char fields, with small sets of possible values. These are "state", "gender", "status", "weapon_type", etc, etc. Frequently we suggest to change such fields to use ENUM column type, but is it really necessary (from performance standpoint)? In this post I'd like to present a small benchmark which shows MySQL performance when you use 3 different approaches: ENUM, VARCHAR and tinyint (+joined table) columns.

In practice you can also often use 4th variant which is not comparable directly, which is using integer value and having value mapping done on application level.

So, first of all, a few words about our data set we've used for this benchmark. We have 4 tables:
1) Table with ENUM:

PLAIN TEXT SQL:

1. CREATE TABLE cities_enum (
2.   id int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
…