With open source software I can install reasonably complete software and try it with my data. This way I get to see how it works in a realistic setting without having to rely on benchmarks and hoping they are a good match for my environment. And I get to do this without having to deal with commercial software sales people.

So I glad to hear the Infobright had gone open source as I have been wanting test a column based database for a while. I was even happier that it was a MySQL based engine as I would already know many of the commands. I decided to run some of the same tests I had run when comparing InnoDB and MyISAM for reporting (http://dbscience.blogspot.com/2008/08/innodb-suitability-for-reporting.html ).  InnoDB performed better than MyISAM in my reporting tests so I’m going to compare Infobright to InnoDB.

The …

Hi5 is one of the world's largest social networks, with over 56 million monthly visitors. It's a company that demands maximum scale and performance from its infrastructure.

As such, it's no surprise that Hi5 recently opted to go with PostgreSQL as supported by EnterpriseDB.

PostgreSQL? Isn't that an open-source database? It can handle that load?

Indeed.

Hi5 runs hundreds of PostgreSQL servers in one of the world's largest commercial OLTP PostgreSQL installations. All Hi5 subscriber data, including user profiles, metadata associated with user photos, and comments, is stored on the company's PostgreSQL databases...In June 2008, the PostgreSQL-based system delivered more than 18.5 billion page views, serving nearly 11 million visitors to the …

One technique that I use to understand MySQL Internals (and ZFS internals in the past) is to look at bug reports. They have lots of useful information in them.

One example is Bug#32149 Long semaphore wait for adaptive hash latch. The bug synopsis could very well have been Why are global locks in a storage engine such a BAD idea. There is lots of useful information about this and the workaround MySQL server uses to work with storage engines that do.. Interesting!

Do you know of any other interesting bugs that document MySQL internals?

One technique that I use to understand MySQL Internals (and ZFS internals in the past) is to look at bug reports. They have lots of useful information in them.

One example is Bug#32149 Long semaphore wait for adaptive hash latch. The bug synopsis could very well have been Why are global locks in a storage engine such a BAD idea. There is lots of useful information about this and the workaround MySQL server uses to work with storage engines that do.. Interesting!

Do you know of any other interesting bugs that document MySQL internals?

as celia wrote earlier, we are in riga, latvia for a meeting of the mysql developers. she is holed up in the hotel room working on a screenplay (or maybe in the atrium where the wifi is better), and i am in a presentation about blogging.

celia already posted pictures from our excursion day on sunday (the day we didn’t sit around in the meeting rooms at the hotel). i took some video which i will figure out how to deal with once we are back home.

EnterpriseDB's Remote DBA Service addresses the market need for managing costs in a tough economy. It could also be an innovation to the open source business model. READ MORE

Recently we were migrating an InnoDB/MyISAM schema to NDB. I was too lazy to calculate all the needed MySQL Cluster parameters (for example with ndb_size.pl) and just took my default config.ini template.
Because I am really lazy I have a little script doing this for me (alter_engine.sh).

But suddenly my euphoria was stopped abruptly by the following error:

 MySQL error code 136: No more room in index file

The usual command that helps me in such a situation is a follows:

 # perror 136

MySQL error code 136: No more room in index file

But in this case it is not really helpful. Also …

This is a picture with a lot of impact. This was from Seedcamp. The question asked was “What tools will you use?”.

Mårten pointed this out to us at the opening speeches at the Sun Database Group Developer’s Meeting. Its interesting to see what technologies are used. MySQL is by far, the most popular database server that all startups seem to use (though to be fair, I see CouchDB and PostgreSQL there too). PHP is about the most popular language (followed closely by Java, then Ruby). Its amazing to see what kind of technologies people are using to build the companies of tomorrow.

Find out more about it, at the Zeitgeist redux on the seedcamp blog.

I had first seen the interesting Rails logo in a talk by Terry Chay, while I was at OSCON, a few months ago.

Now, my esteemed colleague Jay Pipes has it on his laptop. It seems they’re making stickers, even.

Otherwise, my next task is to revamp our Ruby content. Currently, it looks a little sad. It has to at least be as good as Using MySQL With Ruby, no?

Recently we were migrating an InnoDB/MyISAM schema to NDB. I was too lazy to calculate all the needed MySQL Cluster parameters (for example with ndb_size.pl) and just took my default config.ini template.
Because I am really lazy I have a little script doing this for me (alter_engine.sh).

But suddenly my euphoria was stopped abruptly by the following error:

MySQL error code 136: No more room in index file

The usual command that helps me in such a situation is a follows:

# perror 136
MySQL error code 136: No more room in index file

But in this case …