With ndb_restore it is actually possible (talking MySQL Cluster 6.2 and 6.3 here, haven't looked at 5.0 for a long time) to restore a single table into a CSV file that can be loaded using LOAD DATA INFILE.

This can be useful if e.g:

1. You want to extract data from a cluster table and load it into MyISAM/Innodb. This can be useful for reporting/data-mining purposes.
2. You want to load data back into Cluster but into another table looking the same as the original table (not to spoil the original data) for some reason.

Number 2) could be used in scenarios where you want to upgrade the schema by e.g changing the column length of a char(10) to char(255) (not an online operation) and add a bunch of other stuff. Please note that add column is an online operation, changing the column length is not.

Here is an example on how you can do it generate a CSV file using …

Under the title of “From MySQL to Sun“, I’m writing a monthly column to a Swedish-language business publication called “Forum för Ekonomi och Teknik“, about the Sun-MySQL integration.

If you happen to read …

Lotame Solutions, Inc. is always looking for talented individuals. We have many openings in our Technology group, but the one I’m most interested in filling is the newly opened Database Engineer position. The Database Engineer will work with me to maintain Lotame’s entire database infrastructure – including design, development, testing, implementation, monitoring and support. Interested […]

I have been working on a set of efficient C++ classes for storing N-bit (N<=64) values at arbitrary bit offsets into a buffer. Essentially a way to address memory bit-wise, rather than the usual byte-wise or word-wise. The classes support either fixed-sized bitfield storage (eg. say 27-bit values), or compressed values where small numbers are stored in fewer bits than large numbers (for example 0-15 are stored in 6 bits, 16-2**24 are stored in 26 bits, and so on).

The basic idea is of course to save space when storing large amounts of data eg. for a relational database. Today most systems tend to pad much of their numbers to 32 or 64 or whatever bits, wasting space. This is done to allow efficient access, as it is much faster to access data when it is sized and aligned to one of the word sizes supported by the machine.

Or is it really?

Todays CPUs are so fast compared to I/O (disk, network) and even to main …

Teknologföreningen (or TF for short) is the Swedish language student corporation at Helsinki University of Technology. That’s where I started my studies in 1981 at the Department of Physics, together with Mårten Mickos and Michael “Monty” Widenius.

TF has a tradition of each year publishing “ …

Late February 2002 at the recommendation of our then-advisor Florian Müller, I first met with Ingrid Vos at Cafe Glockenspiel in Munich. Right thereafter, her company Marketing Communications became MySQL’s German PR agency.

Ingrid and her Munich based team have accompanied MySQL AB — and specifically MySQL GmbH — now for over six years. It has been a fantastic ride together. She has introduced us to numerous German journalists, and fixed plenty of meetings for Mårten, myself and others. Always with efficiency, a positive attitude, a happy smile and a friendly Austrian touch.

Being acquired by Sun Microsystems means changes in how we …

So I took my concerns over prepared statements to the #postgresql IRC channel on freenode. I pointed out that I think there should be a way to get server side handling of placeholders in statements but without the additional overhead of a second round trip or the drawbacks of overly generic query plans due to not being able to use the parameters in the planning stage. Some people have noted that this feature is available in MSSQL. It also seems to be available in PostgreSQL in the form of PQexecParams and its even exposed in ext/pgsql, though it's only used for sequence reading in PDO_PGSQL. It would be really cool if it could be used when emulating prepared statements (probably with a PostgreSQL PDO …

In 2000, MySQL co-founder David Axmark first told me about having met with Eben Moglen. His descriptions of Eben were always filled with respect and admiration — respect for a person who can keep his integrity and views of how software law should shape the world, and admiration for Eben’s pragmatism and ability to make a difference in the real world.

Over the years since David’s first encounters, Eben and his later estabished Software Freedom Law Center have repeatedly …

My name is Ravi Krishnamurthy - I am the Chief Software Architect here at Kickfire. I’ll be blogging about our thoughts on database technologies for data warehousing. More specifically I’ll be talking about current challenges, directions going forward, and the simplifications for wider market deployments and other ideas.

Data Warehouse (DW) queries are known to be more complex, more demanding, and longer running than OLTP queries. Some of the distinctive features of these DW queries that produce these characteristics are:

1) Table scan: Most OLTP queries are point queries updating or inserting a few transactional data. Most DW queries on the other hand are reporting or business intelligence (BI) queries which typically touch large numbers of rows of data, often computed by sequential table scans over the large data sets.

2) Many/complex joins: Multiple tables with many joins in the …