MySQL has two ways to find tune execution of particular query. First is MySQL Hints, such as SQL_BIG_RESULT, STRAIGHT_JOIN, FORCE INDEX etc. You place these directly into the query to change how query is executed for example
SELECT STRAIGHT_JOIN * FROM A FORCE INDEX(A) JOIN B

The other part is session variable. If you know query is going to require large sort you can do SET sort_buffer_size=50000000 before executing query and SET sort_buffer_size=DEFAULT after executing the query.

I noticed in production hints are used much more frequently than setting session variables for given query execution even though it also can be quite helpful and I believe the problem is it is more complicated. It also requires more round trips to the server but it is not that critical as it is complicated queries which normally need special values.

Especially if you're patching third party application it is much …

Casting can be evil... Assuming that bool will be one byte is a sin. Inside the source we do have my_bool which will be one byte but people forget that they are not the same type!

People will ask this question again and again when they run at the solidDB Storage Engine. The difference means, of course, the difference against InnoDB--the seminal transactional storage for MySQL. It is natural one would think, at first, that solidDB is just a clone of InnoDB because it does the same job of maintaining a transactional table engine under a unified SQL interface. That is true--and must be true--to some extent. However, when you scratch the surface, you may find some pleasant surprises. For example, built-in in solidDB is online backup producing snapshot-consistent backups in a non-blocking fashion. You may find a snapshot-consistent checkpoint a nice feature too. It gives you the freedom to move around the database files (after server shutdown) without the need to care about log files. There are also two concurrency control methods called "optimistic" and "pessimistic".

…

Brian Aker recently wrote about a “skeleton project” for quickly boot-strapping a development environment for a new software project. I do something similar for Perl programs that I want to connect to MySQL. Brian’s skeleton project is different from mine. Mine is just a skeleton for a Perl script, not an entire software project. But perhaps you’ll find it useful anyway. The code included in the file takes care of getting all the info you need to connect to a MySQL instance.

Have successfully merged the 5.0-engines and 5.1-engines trees into the main repositories. Just waiting for the green light to push the 4.1 tree.

It seems that there's a bug with MyISAM tables in any version of MySQL since 4.1 running fulltext indexes.

If you do a FLUSH TABLES (without replication running) and then copy these tables to another DB server (which is essentially a mysqlhotcopy) replication will eventually break with:


Error 'Incorrect key file for table './blogindex/FOO.MYI'; try to repair it' on query. Default database: 'mydb'. Query: 'DELETE FROM FOO WHERE FOO.DATE_FOUND < '2006-12-12 22:35:33'', Error_code: 126


This works just fine for regular MyISAM tables and only breaks for tables which have fulltext indexes. It seems that maybe the index isn't correctly being written to disk?

Today, I plan to merge the engines trees into the main trees. There are some bugs which have been waiting for as long as 2 months!

The Solaris Doors API, originally developed as a core part of the Spring Operating System, is basically nothing more than an RPC mechanism. The Solaris Doors, which are made visible as door descriptors (standard UNIX file descriptors) , relies heavily on threads and allows us to call procedures between processes on the same system. A door client makes a call to a door server which has a thread that is awaken, which passed the scheduling control directly to the thread in the door server. The control and the response is passed back to the calling thread when the door server has completed executing the request.

A door is made visible to other applications by attaching an already existing door descriptor to an existing regular file in the UNIX file system.

Solaris supports the following doors functions

• …

MySQL Lifecycle Policy Calendar

The official MySQL Lifecycle Policy calendar terminates the end of the Active Support Lifecycle for MySQL 4.1 at the end of this year. The product is then entering the Extended Support Lifecycle. Please click on the image and read "What is the difference between Active Lifecycle and Extended Lifecycle support?" to understand the implications of this.

Have an Intel Mac? Rely on SIP soft phones, like X-Lite? Realize that it always crashes?

Try the beta, from CounterPath. It’s not called X-Lite, its beta, so it might eat your babies, but I’ve been using it for a while (because MySQL loves VoIP), and it works a charm. Looks like my office phone is back in business, even when I’m on OS X.