Back in the day we wrote C without support for type checking. Many bugs were missed because of this. Someone wrote lint and many bugs were prevented. Not everyone takes advantage of tools that prevent easily fixed errors. MySQL builds are done without using the -Wall option in gcc to generate more warnings. Nor do they use the -Werror option to fail on warnings. This allows for some silly things in production releases like bug 51289 (return NULL for a function that is declared to return …[Read more]
MyISAM is frequently described and marketed as providing fast
reads when it really provides fast index and table scans. This is
a more narrow use case as fast reads implies great performance
for most queries while fast scans implies great performance for
single-table queries that are index only or do a full table
MyISAM caches index blocks but not data blocks. There can be a lot of overhead from re-reading data blocks from the OS buffer cache assuming mmap is not used. InnoDB and PBXT are 20X faster than MyISAM for some of my tests. However, I suspect that mutex contention on the key cache is also a factor in the performance differences.
While there are many claims about the great performance of MyISAM. There are not as many examples that explain when it is fast. Alas, the same marketing technique is being repeated with NoSQL to the disadvantage of MySQL.
I think I have rpl_transaction_enabled working for MySQL 5.1
and will publish the patch after more testing. I hope to never
port this again but that depends on whether the distribution I
use provides an equivalent feature. Apparently people in
operations enjoy not having to restore slaves after hardware and
Some features require payment up front. They either cost a lot for developers to implement or for users to deploy. Others avoid the up front costs but require payment down the road by users who encounter many problems. I think that MySQL replication has been on the wrong side of this trade off for too long. But things are changing as the replication team has been done a lot of good things for the past few years. I am sure if we …
MySQL uses SQL for data and name-value pairs for configuration
files. Cassandra uses XML for configuration files and something
closer to name-value pairs for data (or name-value-value-...
pairs). Why does it use a stronger data model for configuration
than for data?
While I am writing this in jest I think this is an interesting question.
I am trying to understand the behavior of MYSQL_OPT_READ_TIMEOUT
which can be used to set a client-side read timeout for
connections to a MySQL server. This determines how long a client
will wait for a response to a request. I was uncertain based on
The timeout in seconds for attempts to read from the server. Each attempt uses this timeout value and there are retries if necessary, so the total effective timeout value is three times the option value.I read the code. The documentation is correct. The code attempts to read from the socket three times. I prefer to not have to multiply by three to know the real timeout. But it is too late to change this. Maybe they could add a new option -- MYSQL_OPT_READ_TIMEOUT_DO_NOT_MULTIPLY_BY_THREE.
I encountered this interesting claim while reading the source in sql/net_serv.c. We …
I wish the case for Drizzle could be made without bashing
MySQL. Sometimes it is, but too often it isn't. I guess this is karma.
This isn't a rant against Drizzle. This is a rant against pulling up Drizzle by pushing down MySQL. I occasionally have negative things to say about MySQL, but I usually say them to get the problems fixed. We have lots of complaints about MySQL because we use it in production.
What have I learned about the Drizzle vision?
Drizzle will re-think everything.
- Alas, I have problems to solve today. While I …
A problem with SQL is SQL. It is easy to write queries that
require random IO in the worst case. It is usually easy to find
queries that do too much random IO on a NoSQL system as you must
code the extra data fetches manually.
Digg has begun to write about their reasons for migrating from MySQL to Cassandra. They provide an excellent summary and then describe a performance problem fixed by the migration. I think Cassandra and a few other members of the NoSQL family are amazing technology but I don't think a migration was needed to fix this performance problem. A better index on the Diggs table would have done that. Others have said the same thing. Maybe I don't have all of the details. …
A few years ago MySQL+memcached and PostgreSQL+memcached were the
only choices for high-scale applications. That has changed with
the arrival of NoSQL. Change is good. Open-source monopolies are
not much better than closed-source ones from the perspective of
an end user. I expect MySQL to focus much more on the needs of
high-scale applications to remain relevant. I also expect it to
play better with others as it is no longer the only persistent
data store for high-scale applications.
I think that MySQL+memcached is still the default choice and I don't think it is going away in the high-scale market. But some high-scale applications either don't need all of the features of a SQL RDBMS or are willing to go without those features to scale. This isn't a blanket endorsement of NoSQL as the definition of NoSQL is weak. I am referring to the NoSQL systems that support high-scale.
I don't believe all of the bad press that MySQL …
This is in 5.1.44. It is easy to make mistakes
like this in a large and rapidly changing code base. Why not
compile with -Werror to catch the problem?
if (!value_cached && !cache_value())
my_decimal2double(E_DEC_FATAL_ERROR, &decimal_value, &res);