WFTO – week of MySQL Conference & Expo 2009

This week with our MySQL Conference & Expo 2009 happening, we traditionally
saw low development activity. We will continue our interview series with
Lars-Erik Bjørk.

WFTO interview with Lars-Erik Bjørk

Q: Hi Lars-Erik. May you introduce yourself in two or
three sentences? Personally I would like to know whether
Bjørk, your older sister is OK so far and why you gave up
being the lead singer of A-HA.

Lars-Erik:
I am a 27 year old Norwegian that joined the Falcon team from Sun Microsystems.
Before working on Falcon I worked on HADB (the Clustra database).
The most common question asked to me by strangers actually is:
“Are you related to Björk?”. The first 50 – 60 times I answered “No”, but
lately I have started to answer “Yes”, just for the fun of it.
As revealed by Chris Powers, I used to be a part of the group A-HA.
When the music video for the hit “Take on Me” was recorded in 1984/1985,
I was actually just two years old, but thanks to advanced graphical
manipulation, we managed to pull it off. As Chris said, I quit the band to
pursue a career in software engineering 🙂

Q: In the last months we saw a lot of bugfixes
from you in the index area. I heard that indexes in Falcon have a
kind of prefix-compression. Can you enlighten us a bit about it?

Lars-Erik:
In an index, the keys are ordered, and keys close to each other typically have
identical leading bytes. When this is the case, there is no need to store the same
leading bytes in every of these keys. Instead we store one or two prefix-bytes
that tell how many leading bytes that are identical to the leading bytes of the
preceding key. These bytes are suppressed by prefix compression. This allows
us to store more index nodes on a page, have a bigger fan-out and a lower index tree.

Q: On IRC we see you sometimes being busy
walking your dog. We at Falcon would love to see a picture
of you and your dog! Can you provide us one?

Lars-Erik:
This is 2.8 kilos of pure Chihuahua. His name is Romeo, and he is a ladies man.
He loves ladies of all sizes and shapes. It is important to know that Paris Hilton
takes after us, not the other way around (seriously) 🙂

Q: I recall some bugfixes of you in the area of
Falcon’s encode/decode mechanism. Can you give a brief overview
what the idea about encode/decode is and how it is done in Falcon?

Lars-Erik:
I am certainly no expert on Falcon’s record encoding, and I actually had to
cheat and look at the docs when I got this question, but I can try to say a few sentences about it 🙂

For records in the memory-resident record cache and on disk, Falcon uses a variable
length data encoding that depends on the stored values, and not on the type of the
field. For example, the MySQL data types tiny, short, int, year and some others,
are all represented as unscaled integers. And all null-valued fields are represented
by the same type byte regardless of the type of the field. This encoding saves space,
but makes it impossible to reference a field in the record directly without doing some
processing of the previous fields in the record, as there is no way of knowing the offset
of the field. Therefore, we keep an index of the offsets for the fields we have visited, so
we don’t need to do the same calculations twice.

Eliminating excess space in this way, allows us to do less I/O, which is the real
performance killer in a DBMS. However Kelly Long has discovered that quite a few
cycles are spent doing encode/decode, so it may be that the strategy must be revisited
to squeeze out some additional performance.

Q: Thank you very much for your detailed answers!
Lars-Erik: You’re welcome.

Now back to our usual report: it was MySQL Conference & Expo 2009 and our developers
were busy at the conference.

Since my last report from 2009-04-17 we fixed around 3 Falcon related bugs.
Compared to our last WFTO from 2009-04-17 we have one new test.

The development of our failed/passed tests ratio over time looks like:

• 0.39% – 1/254(this report)
• 0.40% – 1/253 (last report)
• 1.20% – 3/249 (report before last one)

News for this week:

• Vladislav Vaintroub fixed
  • Bug#36993 Falcon reports Index SCHEDULE..PRIMARY_KEY in SYSTEM.SCHEDULE damaged
  • Bug#41840 Unbounded tablespace growth during recovery
  • Bug#43106 Falcon recovery assertion (bdb->buffer->pageNumber == pageNumber) in Cache.cpp

The failing test case is

• falcon_deadlock (known issue)

What about you?

We are interested in you! Where do you use Falcon? What do you do with Falcon? Are there any features you want to see in Falcon? You can test Falcon and get famous by providing valuable bug reports or even test cases for Falcon!

Resources:

• The test language we use is described here: MySQL Test Framework
• List of Falcon related bugs you will find here: http://bugs.mysql.com/saved/FalconBugs
• A preview version of Falcon you will find here: http://forge.mysql.com/wiki/Falcon_Feature_Preview
• Our MySQL Forum dedicated to Falcon related questions is here: http://forums.mysql.com/list.php?133
• Our MySQL/Falcon related mailing list you will find here: http://lists.mysql.com/falcon
• To get latest Falcon source code, please see: http://dev.mysql.com/doc/refman/6.0/en/installing-source-tree.html
• We successfully compiled our sources on Linux 32-bit and 64-bit, FreeBSD 32-bit and 64-bit, Mac/Intel and Mac/PPC, Windows 32-bit and 64-bit, and Solaris/x86 and Solaris/SPARC.