I think I have mentioned Picok before on my blog. This is a system that lets users arrange and configure a number of portlets in order to be able to keep themselves up to date with what's going on in various web applications, similar to iGoogle and netvibes. The difference is of course that this system is entirely open source, so companies can install Picok in their intranet and give Picok direct access to all sorts of internal applications that they could not make available to iGoogle or netvibes. What makes this project all the more exciting is that this system was initially developed as a closed source application for the Raiffeisen bank in Switzerland. This was the first time for me, where I had the opportunity to be part of open sourcing such a large chunk of code.

One of the things we open source proponents mention as a plus point for open source is that developers do not easily get away …

I often see people confuse different ways MySQL can use indexing, getting wrong ideas on what query performance they should expect. There are 3 main ways how MySQL can use the indexes for query execution, which are not mutually exclusive, in fact some queries will use indexes for all 3 purposes listed here.

Using index to find rows The main purpose of the index is to find rows quickly - without scanning whole data set. This is most typical reason index gets added on the first place. Most popular index type in MySQL - BTREE can speed up equality and prefix range matches. So if you have index on (A,B) This index can be used to lookup rows for WHERE clauses like A=5 ; A BETWEEN 5 AND 10 ; A=5 AND B BETWEEN 5 AND 10 it however will NOT be able to help lookup rows for B BETWEEN 5 AND 10 predicate because it is not index prefix. …

In my recent post on the EU antitrust regulators' probe into the Oracle Sun merger I did not mention an important class of stakeholders: the MySQL-based special purpose database startups. By these I mean:

• 
  
• Kickfire
  
• Infobright
  
• Calpont
  
• ScaleDB
  

I think it's safe to say the first three are comparable in the sense that they are all analytical databases: they are designed for data warehousing and business intelligence applications. ScaleDB might be a good fit for those …

I'm pleased to announce the release of Spider storage engine version 2.3(beta).
Spider is a Storage Engine for database sharding.
http://spiderformysql.com/

The main changes in this version are following.
- Add UDF parameter "connection_channel".
  This parameter is used for increasing background parallelism to same remote server by using multiple connections.

Please see "99_change_logs.txt" in the download documents for checking other changes.

Enjoy!

We just had a booboo in one of our internal systems, causing it to not come up properly on reboot. The actual mishap occurred several weeks ago (simple case of human error) and was in itself a valid change so monitoring didn’t raise any concerns. So, as always, it’s interesting and useful to think about such events and see what we can learn.

Years ago, but for some now still, one objective is to see long uptime for a server, sometimes years. It means the sysadmin is doing everything right, and thus some serious pride is attached to this number. As described only last week in Modern Uptime on the Standalone Sysadmin blog, security patches are a serious issue these days, and so (except if you’re using ksplice sysadmin quality has become more a question of when you …

There’s a really important difference between a unique index (MySQL’s answer to a “unique constraint”) and a primary key in MySQL. Please take a look at this: CREATE TABLE `t` ( `a` int, `b` int, `c` int, UNIQUE KEY `a` (`a`,`b`) ) The combination of columns a, b should uniquely identify any tuple in the table, right? select * from t; +------+------+------+ | a | b | c | +------+------+------+ | 1 | 2 | 3 | | NULL | NULL | 1 | | NULL | NULL | 1 | | NULL | NULL | 1 | +------+------+------+ Wrong.

Over the last 5 years, I’ve read so many articles about how X doesn’t scale. PHP, MySQL, SQL Server, Apache, you name it – everything gets a bad rap. Everyone has a different idea of scale and size, and sadly most people think their site with 1 million page views a month can’t handle the load because whatever technology they chose to use supposedly doesn’t scale.

Guess what folks – the problem probably isn’t the language you chose, or the database you’re using. Unless you’re actually big (many millions of pageviews per day), you can usually run just fine with a straight up LAMP stack on a few servers. The real issue is that your dev team has no idea how to write software or use the tools they have available.

At this point, I wonder – what is everyone’s expectation? At what point does someone say “oh, X scales great! One box is handling my web server, data storage, video conversion, at 20 million page views a …

For many years, building and installing third-party software on Solaris has been a huge pain. For people who do not use pkgsrc, that is.

Originating from the NetBSD project, pkgsrc is a source-based cross-platform package manager. If you’ve used FreeBSD ports, then it is very similar as it derives from the same codebase, so the basic premise is that you:

$ cd /usr/pkgsrc/www/apache22
$ make package

and pkgsrc will download the source for Apache 2.2, compile it and all dependancies, install it on the local system and create a package which can be installed on other similar systems.

However, we’ve taken ports further and applied the NetBSD philosophy of portability, meaning that it not only works on NetBSD, but across all *BSD as well as Linux, OSX, HP/UX, AIX, IRIX, QNX, Windows (via Interix), …

How large can a column of the data type POINT be: 10 bytes, 100 bytes, 1k, 10k? No… think Enterprise! PHP will allocate 4GB of RAM if you use the Prepared Statements of ext/mysqli and the MySQL Client Library (AKA libmysql) to fetch a POINT column. Of course, the MySQL native driver for PHP (mysqlnd) does better!

To understand why ext/mysqli can allocate up to 4 GB of RAM to fetch a POINT column we need to have a look at the MySQL C API. PHP itself is written in C and in a way ext/mysqli is just a plain vanilla C API client application. The C API is provided by the MySQL Client Library which has been called "libmysql" in the past. The MySQL Client Library implements the MySQL Client Server Protocol. The MySQL native driver for PHP (mysqlnd) is an alternative implementation of the MySQL Client Server Protocol and it is part of PHP source code as of PHP 5.3. If that is a new to you, please have a look …

How large can a column of the data type POINT be: 10 bytes, 100 bytes, 1k, 10k? No… think Enterprise! PHP will allocate 4GB of RAM if you use the Prepared Statements of ext/mysqli and the MySQL Client Library (AKA libmysql) to fetch a POINT column. Of course, the MySQL native driver for PHP (mysqlnd) does better!

To understand why ext/mysqli can allocate up to 4 GB of RAM to fetch a POINT column we need to have a look at the MySQL C API. PHP itself is written in C and in a way ext/mysqli is just a plain vanilla C API client application. The C API is provided by the MySQL Client Library which has been called "libmysql" in the past. The MySQL Client Library implements the MySQL Client Server Protocol. The MySQL native driver for PHP (mysqlnd) is an alternative implementation of the MySQL Client Server Protocol and it is part of PHP source code as of PHP 5.3. If that is a new to you, please have a look …