Skip to content

# Month: November 2011

## Percona Live: MySQL Conference And Expo 2012 – a note on proposals

MySQL mysqlconf November 29, 2011November 29, 2011

As a member of the conference committee I review the session and tutorial proposals for the Percona Live MySQL conference in Santa Clara, 2012.

The sessions are expected to be technical, and I’m happy the proposals follow this guideline. I use Giuseppe‘s and Baron‘s general guidelines for submitting a proposal. I wish to humbly add a couple notes myself.

#### Be fairly brief

Explain your session/tutorial as clearly as you can. The reader should be able to get the general impression of the session from two or three paragraphs. Some can make a point in two sentences; for most it would take somewhat more.

If you’re going to talk about some database feature, for example, please do not write the manual for that feature. That’s for the session itself. Just explain how you’re going to discuss the feature, and why it should be of interest (e.g. what the benefits of this feature are, the risks or pitfalls, the ingenious C code behind it or the quirks of the operating system involved).

#### Clarify

It’s important for me to understand two things when reading a proposal, which establish the grounds for better evaluating the proposal:

- Who the target audience is (newbies, developers, DBAs, Linux internal experts etc.)
- To what depth are you going to deliver the content you describe.

That is not to say you should explicitly state “This session is for MySQL DBAs”, but the attendee should be able to easily decide whether your session appeals to his type of work or expertise. I, myself, have happened upon sessions that were completely different from what I expected. To illustrate, I give two examples, while not disclosing the exact details:

- A session which was about locking in database. I got the impression it was about ways to avoid locking, issues with mutexes etc. It turned out to be a discussion between the presenter and a few member of the audience about the specific code internals, lines 667-684 in the lock_module.cc file, and the recently reported bug. To me it was more like the weekly rnd meeting of some company. I couldn’t understand anything of the entire talk.
- A session promising insight on working out great scale-out with some product: I was expecting to hear of the “DOs and DON’Ts”, or of great configuration and implementation tricks on the subject. However, it turned out to be more of a general talk on “how we used the product in our company and found it to work great”.

The two sessions above were perfectly valid, and had their place in the conference. But were poorly described in the two respects I mentioned.

A great submission, in my opinion, is one where attendees get what the expect, and don’t shyly leave the conference room 15 minutes into the talk.

Submit a proposal here.

## Reading results of SHOW statements, on server side

MySQL common_schema Hacks INFORMATION_SCHEMA SQL November 25, 2011

SHOW statements are show stoppers on server side. While clients can get a SHOW statement as a result set just as any normal SELECT, things are not as such on server side.

On server side, that is, from within MySQL itself, one cannot:

>     SELECT `Database` FROM (SHOW DATABASES);

One cannot:

>     DECLARE show_cursor CURSOR FOR SHOW TABLES;

One cannot:

>     SHOW TABLES INTO OUTFILE '/tmp/my_file.txt';

So it is impossible to get the results with a query; impossible to get the results from a stored routine; impossible to get the results by file reading…

#### Bwahaha! A hack!

For some SHOW statements, there is a way around this. I’ve been banging my head against the wall for weeks now on this. Now I have a partial solution: I’m able to read SHOW output for several SHOW statements. Namely, those SHOW statements which allow a LIKE or a WHERE clause.

For example, most are familiar with the following syntax:

>     USE mysql;
>     SHOW TABLE STATUS LIKE 'user';

However not so many know that any SHOW statement which accepts LIKE, can also accept WHERE: Continue reading » “Reading results of SHOW statements, on server side”

## Xfce is the new Gnome 2

Linux November 22, 2011

I’ve recently had it with Ubuntu’s Unity.

Wait, why Unity?

Because my gdm was consuming so much CPU my laptop had its fan working non-stop. I’ve researched and tweaked and installed and removed – and finally moved to Unity to solve that. There may have been another solution, but that’s an old story now.

Thing is, that used to be Gnome 2, a great environment for a software developer. Easy keystrokes to move between your apps, intuitive mouse gestures. Unity presented with a very slick look, but a counter-productive environment. Perhaps it’s great for people opening one Firefox window and one Libre Office Writer document. It does not work as well for people with 3 different browsers, 5 terminals on 2 different desktops, eclipse with 4 separate perspectives, and Gimp, which opens up with 5 windows up front. Continue reading » “Xfce is the new Gnome 2”

## Quoting text JavaScript/Python style

MySQL SQL Syntax November 15, 2011November 15, 2011

Unless your MySQL is configured to use ANSI_QUOTES in sql_mode, you are able to quote your text in one of two forms: using single quotes or double quotes:

>     UPDATE world.Country SET HeadOfState = 'Willy Wonka' WHERE Code='USA'
>     UPDATE world.Country SET HeadOfState = "Willy Wonka" WHERE Code="USA"

This makes for JavaScript- or Python-style quoting: you quote by your needs. Say you have a text which includes single quotes:

> It is what you read when you don’t have to that determines what you will be when you can’t help it. – Oscar Wilde

You wish to insert this text to some tables. You could go through the trouble of escaping it:

>     INSERT INTO quotes (quote, author) VALUES (
>       'It is what you read when you don\'t have to that determines what you will be when you can\'t help it.', 'Oscar Wilde');

or you could just wrap it in double quotes:

>     INSERT INTO quotes (quote, author) VALUES (
>       "It is what you read when you don't have to that determines what you will be when you can't help it.", 'Oscar Wilde');

I find this useful when using SQL to generate queries. Take, for example, eval() for MySQL: the statement: Continue reading » “Quoting text JavaScript/Python style”

## Oracle ACE

MySQL award community Open Source November 4, 2011November 4, 2011

I am honored to have been nominated for, and to have received the Oracle ACE award.

Nomination for this award is made by Oracle community members, and in this case those being Oracle employees Keith Larson and Dave Stokes. The award is given by Oracle for my involvement in the Oracle/MySQL community and for my contributions.

While open source involvement is generally done in the mere purpose of sharing knowledge and solutions, recognition plays a role in it. For the most part, one who writes blogs wants them to be read, and one who writes code wants it to be downloaded and tested, which is an elemental type of recognition, and what I aim for.

The recognition given by the Oracle ACE award makes for a wonderful complement, being given by the corporate with whose products I’m involved. It is great to get a surprising “Hey, good work” acknowledgement. Sun/MySQL told me that back in 2009, and I was caught utterly unprepared. I am still unprepared!

Thank you, the community, the people from whom I learn and benefit, anyone who ever reads my blogs, who comment, anyone who tries my code, who provides feedback, the multitude of people writing, sharing, blogging, speaking, coding, fixing, spreading, who make it such a great community.

Thank you, Oracle for this award!

## Self throttling MySQL queries

MySQL Hack MyISAM Performance SQL Stored routines November 1, 2011November 1, 2011

Recap on the problem:

- A query takes a long time to complete.
- During this time it makes for a lot of I/O.
- Query’s I/O overloads the db, making for other queries run slow.

I introduce the notion of self-throttling queries: queries that go to sleep, by themselves, throughout the runtime. The sleep period means the query does not perform I/O at that time, which then means other queries can have their chance to execute.

I present two approaches:

- The naive approach: for every 1,000 rows, the query sleep for 1 second
- The factor approach: for every 1,000 rows, the query sleeps for the amount of time it took to iterate those 1,000 rows (effectively doubling the total runtime of the query). Continue reading » “Self throttling MySQL queries”