On what was said by Monty.

I think that in any dispute there are never two separate positions; there’s no a “black position”, there’s no a “white position”. I think about a “gray gradient” where there exists several different positions and opinions. Maybe the truth in this case is “gray” colored!
As a good Italian I stay in the middle thinking that there are some truths in the criticism of Monty, but at the same time I think there’s also exaggeration.
But mine is not a relevant opinion! I don’t have a deep knowledge of MySQL AB organization and I don’t know all the facts and the people involved. My contribution to the discussion is very simple and humble, just to say that I’m using 5.1 version since August 2008 in a more than 2 million queries per day production environment and I never experienced a server crash (ok, sometimes it crashed … but that was my own fault!).
For the goals of my …

Follow the link: MySQL 5.1 Use Case Competion

… California dreamin’

Here is just a simple stored function to capitalize the first letter of each word in a string.

Sometimes it’is useful to convert name of cities and persons using the correct capitalization.

DROP FUNCTION IF EXISTS `capitalize`;
DELIMITER $$
CREATE FUNCTION `capitalize`(stringa TEXT) RETURNS text
    DETERMINISTIC
BEGIN

        DECLARE i INT DEFAULT 2;
        DECLARE sout TEXT;
        DECLARE ucn INT DEFAULT 0;

        SET stringa=LCASE(TRIM(BOTH ' ' FROM stringa));
        SET sout=UCASE(LEFT(stringa,1));

        WHILE i 

Example:

mysql> SELECT capitalize(' new york ');
+--------------------------+
| capitalize(' new york ') |
+--------------------------+
| New York                 | 
+--------------------------+

I started to use MySQL 5.1 in a production environment at the beginning of August 2008. My purpose was to log all my web visits (more than 1 million pages per day) and to calculate real-time and on-demand statistics.
New features such as partitioning and event scheduler gave to me the opportunity to solve some problem.

I sent my “use case” to the competition proposed by mysql.com and now there’s an article on the developer section of the site where you can read what I did.
If you like, please read it.

(If you are here following the link on the article on mysql.com … don’t mind … and thanks)

In MySQL 5.1 Cluster Certification Study Guide at page 151 there’s the following sentence: “InnoDB operates with the REPEATABLE READ isolation level, which still allows phantom reads but suppresses non-repeatable reads”.

The sentence is wrong: the REPEATABLE READ isolation level for InnoDB engine doesn’t allow phantom reads.

In some database systems, REPEATABLE READ isolation level allows phantoms, such that if another transaction inserts new rows in the interval between the SELECT statements, the second SELECT will see them. This is not true for InnoDB; phantoms do not occur for the REPEATABLE READ level. SERIALIZABLE isolation level is similar to REPEATABLE READ with the additional restriction that rows selected by one transaction cannot be changed by another until the first transaction finishes. (as stated by MySQL 5 Certification Guide)

Here is an example to demonstrate such a behaviour.

To …

I’m reading the guide, but I’m still too busy with my work to read it proficiently. In order to pass the exam I have to read it again focusing all the details.

But, after reading the first 6 chapters (more then 50% of the entire book) I found the guide useful and simply understandable … and, thanks to lulu.com, it seems to me to be cheapest.
Well done authors!!!

I’m excited and a little bit worried about the aquisition of MySQL AB.

Sun has lots of billions, has lots of big customers and a great interest in competing with Oracle. These issues could be the ones to think about a more brilliant future for mysql.

I see in future a new SAMP paradigm (Solaris-Apache-MySQL-PHP/Perl/Python).

But I’m also a little bit worried.

Just to say I’ve bought the book as soon as it was available on lulu.com.

I was waiting for it from april.

The optimizer is the part of the mysql server whose responsibility is to discover the optimal plan (the execution oath) to solve an SQL query.
When dealing with joins there exist various execution paths depending on the number of tables involved. The number of possible plans to investigates grows exponentially with the number of tables. This is not a problem for queries with few tables (less than 10) but could be a serious problem when the number of tables climbs.
When dealing with dozens of tables the time spent to evaluate all possible plans to solve the query is longer than the execution of the query itself. Not good.
Starting from version 5.0.1 MySQL introduces a flexible method to avoid the possible bottleneck when you have lot of tables joined in a query.

Using the system variable optimizer_prune_level (possible values are 0 or 1) you can tell the optimizer to skip certain plans from being inspected based …