The Clash of the DB Egos

The Clash of the DB Egos

One of the most popular keynotes of the MySQL Conference & Expo 2007 was called "The Clash of the DB Egos". It was a fight amongst seven database luminaries, all playing an important role either within MySQL AB or as providers of Storage Engines that work closely with MySQL. This article attempts at giving a picture of what the fight was about, through reciting the egos and the questions posed to them by the referee.

The Rules Of The Battle

Kaj: My name is Kaj Arnö. I'm MySQL's Vice President of Community Relations, and I'm your referee (showing the striped shirt).

Kaj: I will be introducing 7 egos here this morning, one for each bar stool, one at a time. And then I will provoke a fight between them.

Kaj: I don't want to set your expectations too high, but I might also have to pull them apart. For that purpose, if they don't fight according to the rules of the game, I will blow the whistle. I will now do a beta test of it [stepping away from the microphone, making noise].

Kaj: I might have to do that to give them a penalty. They can get penalties for

• marketing fluff,
• mumbling,
• excessive pontification (being too big egos), or for
• avoiding the question.

Kaj: So let us have our first ego, who is none other than the father and co-founder of MySQL, Michael "Monty" Widenius!

[Music: Monty Python's Flying Circus].

U M Widenius

Kaj: Gomorron Monty! ["Good morning" in Swedish]

Monty: Gomorr'n.

Kaj: So, back in the 1980s, both you and I had our own companies, and were providing solutions to our customers. One thing that connected us was that we both used databases. One thing that set us apart was that you were writing some ISAM routines yourself, and I was using a real database. Why did you do that?

Monty: To solve the needs that I had. The commercial databases at that point in time didn't fit my needs.

Kaj: But is it not a bit exaggerated to write your routines because of that reason?

Monty: Back then, there were no open source databases I could use that were suitable, so I had to start writing my own.

Kaj: So you are already fast-forwarding to when you were writing MySQL. To begin with, you were only writing some ISAM routines. Then, at some point in time, you decided on top of ISAM to write an SQL layer. Now, why was that?

Monty: The old database was used for data warehousing. We had lots of customers for it. As the world evolved, and the Internet started to raise its nice head, we needed to get the data out for our customers. SQL seemed to be a suitable way for embedding things easily within a browser. So I wrote an SQL layer on top of my own code to be able to access data easily.

Kaj: To me it still seems like an exaggerated solution. Did you write your own text editor as well?

Monty: Actually, I did. But that was before I switched to Unix and found the best text editor in the world: Emacs.

Kaj: I think we should go back to databases, and your database. Why did you go open source with it?

Monty: When I wrote MySQL, I couldn't have done it without the open source tools that existed: gcc, Emacs and other stuff. During the years of using these, David and I always wanted to be able to give something back to the community. Before we had MySQL, we had lots of tools, but they were very specialised. So they were not really suitable for large distribution. MySQL was the first thing for which we thought "there may be somebody who could have a little use for it".

Kaj: Thank you Monty! Our next ego shares your native country, and your stubbornness. He has worked on several databases, including Solid, and is most known as the father of the InnoDB storage engine: Heikki Tuuri!

H M T Tuuri

[Music: Säkkijärven Polkka]

Kaj: Huomenta Heikki! ["Good morning" in Finnish]

Heikki: Huomenta, huomenta!

Kaj: For those you who didn't know that tune, it was the first popular ring tune in Finland for the Nokia phones. I think that's a good characteristic for you. So, Heikki I'll ask you a similar question that I asked Monty: What made you want to write your own database?

Heikki: I wanted to make the world's best and fastest database.

Kaj: You now say what you wanted to do. But what was the reason for creating a database of your own?

Heikki: OK, OK, now I see. It's that stubbornness.

Kaj: Being stubborn, how did you get started?

Heikki: I worked for Solid, and then I went to the university and looked through the whole library about databases.

Kaj: And then you wrote "begin", and then you went Open Source with it?

Heikki: I started coding when at the university in 1995, and it was not my intention to make it open source, because open source was not that normal at the time. But when I met Monty in August 2000, Monty said that I should make it open source.

Kaj: And you obeyed?

Heikki: Yes.

Monty: I want to give Heikki credit for his good judgement.

Kaj: Heikki interfaces to the MySQL code through what is called the Storage Engine API. Monty, why did you introduce such an API? And how did you have Heikki integrate?

Monty: The story of that one is very short. My old product (called UNIREG) worked with a commercial ISAM implementation, and I also wrote my own ISAM implementation. I wanted to make it easy be able to access both types of data at the same time. So in about 1986, UNIREG could work with different engines, and the only way to do that efficiently was to have an API.

Kaj: I think we will have to come back to the Storage Engine API. But let us first go for some more egoes. So let me now fast forward to 2003, and look at another new database, MySQL Cluster. This database was the fruit not of a single individual ego, but of a team in a large company, Ericsson. Within this team, there was at least one big ego, though. This person is the father of five children and the architect of MySQL Cluster, Mikael Ronström.

U M Ronström

[Music: Dancing Queen by ABBA]

Kaj: Gomorron Mikael!

Mikael: Gomorron!

Kaj: So we didn't hear all of the tune. It was supposed to be The Winner Takes It All by ABBA, a competitive song from Mikael Ronström's native country of Sweden. I think you should soon start to get a bit more aggressive here. The audience has paid for seeing a fight here, OK?

Mikael: OK, let's have more fighting here, sure, but I don't want to get injured. If it's a competition though, I will be very aggressive.

Kaj: First I have a questions related to the 3NF (the third normal form). So Mikael, true DB egos like E F Codd and C J Date all go by two initials. Yours are U M quite as Monty's, and they stand for Ulf Mikael, quite as Monty's. So, Ulf Mikael Ronström, does that mean that first names are bad unique identifiers?

Mikael: Obviously not! It wouldn't even help to add birth year, since we share that one too.

Kaj: Getting back to databases: Mikael, how did it feel to be an entrepreneurial ego trapped in the body of a large company?

Mikael: Ericsson is a technical company with a lot of entrepreneurs, or rather intrapreneurs. I had a vision of what I wanted to do. And I guess I was a bit stubborn as well. At least I have been accused of that sometimes.

Kaj: How did your stubbornness react to the Storage Engine API?

Mikael: My first reaction was positive. I never wanted to write an SQL engine. So I was happy to see that I got rid of that problem, by implementing the Storage Engine API instead.

Kaj: So Monty, Heikki, Mikael, you are far more polite than I had expected, and far more polite than necessary. We need somebody who can disagree with you on stage. Let me introduce the father of I don't know how many databases, and now the Falcon Storage Engine, Jim Starkey.

J A Starkey

[Music: Rocky Balboa; Jim enters wearing a hat, then puts his hat for dollar bills on the floor; other egos later contribute funds]

Kaj: Good morning Jim!

Jim: Good morning Kaj!

Kaj: This is the first time I'm greeting somebody in English here. First I greeted one in Swedish, then Finnish, and then Swedish again. Do the United States still have anything to say in the future of databases?

Jim: Well gosh, when you Scandinavians needed some new technology, where d'ya come?

Jim: We do transactions.

Jim: I'll explain that to you later.

Kaj: You've created something like four databases, right Jim?

Jim [thinking]: Uhmm, ... five? I don't know.

Kaj: You had a full table scan there, I see?

Jim: Yup. I'm a little bit older than these other gentlemen.

Kaj: So you must guess the question coming up: What's the difference now, what different considerations did you have to take when designing this database? What is different today, that caused you to rethink the architecture?

Jim: Oh, it does transactions, it does blobs, it does all sorts of nice things, it uses memory differently, it uses threads differently. We're bordering on marketing fluff -- blow your whistle! I'm repeating myself!

Kaj: I was more thinking about what has changed in the marketplace? What has changed in technology, rather than what are the cool and nifty little features, the marketing fluff that you were talking about.

Jim: Oh! The marketplace is wonderfully different. Back in the old days, we had big computers and small people. Now we have big people on little computers. But they are all connected across the world, and I think the primary challenge we have in the database world is building database systems that are friendly to the web. Rather than teach the web to use punch cards, we should have databases deal with the web.

Four DB Egos

Kaj: Before introducing more egoes, let's have the four first egos battle a bit.

Mikael: Yes Jim, my first question to you is obviously: Why did you have to do five databases, why didn't you do it right the first time?

Jim: Why do you ask that question? You said you were an entrepreneur! I can give you the answer: You sell them and start over!

Jim: Starting over is important, because you learn new tricks. And to get rid of the old stuff, you have to start over. The only downside in creating new databases is that you have to write strange date conversion routines.

Kaj: I was just going to blow the whistle for financial fluff, but I'll return to technology. I hear, amongst the four of you, you, Jim, keep telling me you are the biggest fan of the Storage Engine API, right?

Jim: Oh yes, the Storage Engine API. I've been thinking about this question, because I thought it might come up. And I have an analogy about what an API is. Now suppose you had a TV set and you went out to buy a DVD player. Now we have an interface here. You open the DVD box and you have what's called an Instruction Manual. And it says: Take the cables. Find the part of the TV that says AV1. Match the connectors to sockets of the same colour and shape, and then watch your DVD. That's what an interface is. Now your TV has your S-Video for backward compatibility, your Component Video for current and HDMI for future compatibility. You have backwards and forwards compatibility, and that is a good thing.

Jim: We take the MySQL Server and we're gonna do the same thing. We open up the whole back door. We look at a whole bunch of wires. And then you pull up a piece of paper, it doesn't say "Instruction manual", it says "Marketing statement". What you do is, in your right hand, you grab the bundle of wires, you stick in elbow deep into the box, and connect them as appropriate.

Mikael: Find the error!

Jim: I believe very strongly in the Storage Engine interface. I believe it's a great message, and I think it's a great way to introduce new technology for people who don't know how to write a SQL parser.

Kaj: I detect a slight mismatch between your last two statements.

Jim: .. but! We've got to make it simple, we've got to make it stable, we've got to make it easy to use.

Kaj: So Monty, do you have anything to say in your defense?

Monty: I think Jim is right. But he is a little bit misguided.

Kaj: So Monty, you yourself are working on an enhancement to MyISAM, a new storage engine. What kind of changes would you want to see happening in the storage engine API?

Monty: Actually, run transactions. The first engines didn't have transactions. And, in that regard, the interface is more than crude. We need to clean it up. And there are a lot of things that have changed during the twelve years that the API has existed.

The nicest thing I can say about the API is that it works for many vendors and has done so for many years. And it has potential to be even greater.

Kaj: Heikki, is it great?

Heikki: No. It is very very complex.

Kaj: Mikael, what's your opinion on this one?

Mikael: Some people say it is a one week job to get something and it's probably one week and you have something going, but let's face it, it's three years of trial and error to get something really working, and we obviously can make that simpler.

Mikael: And it's also pretty interesting. I am doing a clustered engine. We have transactional engines, we have clustered engines, we have non-transactional engines. There are a lot of things that a clustered engine can do, that transactional engines can't do, and vice versa. You simply cannot mix them completely.

Jim: You figured this out in 1 1/2 years? Two months to go!

Kaj: Can you mix and match, Monty?

Monty: Engines?

Kaj: Yes!

Monty: We are doing it. And we need to be able to do even more mix-and-matching in the future. Because the engines are leaping ahead of what we are doing right now, and crossing new bridges. We need to have an API that is ready for it. So we need to modernise it, that's obvious. The question is just, how. And that's why we need guys with the expertise that we have here, who can help us do that.

Kaj: Transactions. Jim, you are the most aggressive in claiming that everything is fully ACID. Are you fully ACID?

Jim: Am I what?

Kaj [slowly]: Are you fully ACID compliant?

Jim: I am absolutely ACID compliant! I'm from the 1960s.

Jim: Don't you see what that means?

Mikael: Can you take a backup?

Kaj: Don't you see any grey zones here? Can't we be halfway ACID, a little bit less ACID, like ACId with a lower case d, to gain some performance?

Jim: In Windows, it's case insensitive. But if you're talking about running on Unix, well then it's case sensitive. And if your talking about working on the Macintosh, well, that's more complicated as it depends on the file system you're using. So can you change the rules?

Kaj: I will blow the whistle for confusion here!

Jim: That's what I am talking about! Confusion!

Mikael: That's the C in ACID!

Kaj: Heikki, do you see shades of grey? Can we make InnoDB a little bit less ACID, and get something for it?

Heikki: Yes, but I am reluctant, as I explained in my talk yesterday. It creates deadlocks. But I disagree a bit with Jim about the ACIDity of Falcon, regarding its support of mathematical serialisability.

Kaj: Jim?

Jim: Me? I couldn't hear what he was saying.

Kaj: The mathematical serialisability of Falcon!

Jim: ACID is not serialisable. That's the problem. Let's see. ACID is Atomic, and Falcon is atomic. And it's Consistent, it provides a consistent view of the database, you don't see phantoms, you don't see records that haven't been stored yet. I is Isolation, you don't see other transaction that haven't been committed. And it's Durable! It's durable as long as your disk works.

Mikael: Isolation is serialisability!

Jim: No, isolation isn't serialisability ...

Mikael: No, no, no!

Jim: Serialisability, I think that is a fine thing. We all know how to do serialisable, and that's the easy part. You do one transaction at a time and it works, but it does have its drawbacks.

Kaj: Monty, you don't ask for the word if there's a clash of the DB egos. You just go ahead and shout!

Monty: I want to go back a bit in time. When I started writing MySQL, I was more concerned about making a stable database that doesn't crash, than having a database that can crash the whole time, and that needs recovery and transactions to keep it up.

Kaj: Now it's time for us to get some more egos up on stage. Our next Ego is the Architect and CTO of Solid, Ari Valtanen.

A J Valtanen

[Music: Sledgehammer by Peter Gabriel]

Ari [pointing to Jim's hat]: May I contribute to your fund?

Jim: Follow this man's example!

Kaj: Huomenta Ari!

Ari: Gomorron, hyvää huomenta!

Kaj: So, we're back greeting in non-English again, are we, Ari?

Ari: Yes.

Kaj: That was an exhaustive answer. So, you are an established database player with Solid. What made you want to provide your database as a Storage Engine in MySQL?

Ari: To be honest and frank and answer your question directly: Back in the autumn of 2005, Mårten was very persuasive and convincing that we should do it.

Kaj: And he succeeded just like that?

Ari: He was right, and then we did that.

Kaj: Bearing in mind the risk of marketing fluff and whistle blowing, who should be using your database?

Ari: Anybody who is interestied in transaction and durability, high-availability also. It's a transactional engine, and I believe in the same things as Heikki and Jim are advocating, ACID.

Mikael: Do you provide the HA functionality of MySQL Cluster, too?

Ari: Definitely not all.

Heikki: We are not advocating fluff.

Ari: Thank you for making that clear.

Kaj: Thank you Ari. Let's have our following ego up on stage. He is the father of the Nitro Storage Engine, Paul Whittington.

P H Whittington

[Music: TNT]

Paul (pointing to Jim's hat): I don't have a dollar. I haven't sold yet, that's why.

Kaj: Morning Paul!

Paul: Good morning!

Kaj: Let's first ask, what is the Nitro engine, or the Nitro database all about?

Paul: The Nitro database is all about really high speed, really large volumes, and really fast queries.

Kaj: How do you make these queries really fast? And I understand from having talked to you that "really fast" means faster than MyISAM. Monty, is that possible?

Monty: All the different engines can do things faster in some way. There is no perfect solution. By combining different technology, you can do things faster. That's why we need the Storage Engine API!

Kaj: Let's give Paul the word. I hear you do magic with indexes. Is that why you're so fast?

Paul: Yes, that's right. We are able to do what we call "positional awareness". So any index entry knows where it is in the index, and that turns out to be very useful. And we also can do things called "aggregates". So, at any point in the index, you can know the SUM of any field in the record, at that point in the index. And by doing so, we can do very large analytical queries, averages, standard deviations, sums of various kinds, in basically two index reads for any piece of the index.

Kaj: So what this means is that you have more stuff in the index, you have the AVGs and SUMs there, and that's something that distinguishes you from the rest?

Paul: Yes, that's right.

Jim: Doesn't that mean that the DBA has to know the questions in advance?

Paul: Yes, you're absolutely right. We have found in our work with our customers, that the customers have predictable query loads. They know the kind of questions that are going to be asked. But they have extremely high insert rates and hundreds of millions of records. And they need the answer right now, because the network's down! Or, I want to know how to maximise the profitability of a flight coming in to O'Hare, in a snowstorm, against the wind.

Kaj: So, against the wind, what made you want to provide your database as a storage engine with MySQL?

Paul: We have a security product line as well. As we have been selling that product line, customers keep saying "Hey, can I use your database, to do what you're doing?". We answer "Well, you can ... I suppose." And as we have looked at how we can offer that to them in a way that they could use it, MySQL was the perfect fit. That's because they already mostly know MySQL, and we can plug a storage engine down underneath. Our customers can mix and match it with Cluster or Inno or Falcon and do transactional work and non-transactional work at the same time. That's how we ended up here!

Kaj: Thank you Paul! Let's now go for our final ego. There's a bit of a longer introduction here. You may have read my blog that I had hoped for the real big DB egos, those who created the database industry, E F Codd and C J Date, to be here with us. Neither could come. E F Codd passed away a few years ago, and C J Date had some other excuse, but indicated to Jay Pipes that he might be available next year. So instead, I have the pleasure to introduce Mike Smith from IBM.

R M Smith

[Music: Feeling Blue]

Kaj: So I think most people in the audience have heard about your company ...

Mike: Or work for it!

Kaj: ... and some of them are even aware that you, as a company, are somehow involved in databases, right?

Mike: We have a database, that's true.

Kaj: So I suppose you have come up here to tell the world that you are now providing DB2 as a Storage Engine, or what?

Mike: What we are here to talk about today is to provide a storage engine for a specific product in the IBM family. We have a product, that used to be AS/400, was iSeries, now System i, that was developed the same way that Monty had started. We had a relationally oriented database and we eventually put an SQL layer on top of it. The difference to what we had, as opposed to what Monty had, is that we also had an operating system and some hardware. And we very deeply integrated those together, such that virtually all of the data that's stored in our bit range systems, is in the DB2 storage engine that's part of the System i today. What we are looking at doing with the storage engine is to make that data available to all MySQL applications. We will be able to open up all that data by providing the DB2 Storage Engine for System i against all the MySQL applications. On the flip side, we also have a lot of applications that are written for the DB2 storage engine, as well. And by providing a storage engine for MySQL, we'll be able to store that data into DB2 in all the other applications. So it's about new applications to old data -- old applications to new data.

Kaj: You answered my two following questions as well!

Mike: Yes!

Voice from the audience: Where is Microsoft SQL Server?

Kaj: Microsoft SQL Server? There are no more chairs here!

Another voice from the audience: It crashed on the way here!

Kaj: Of the audience here, not everybody is on i5. What do you think is the significance for this particular audience of the announcement that IBM and MySQL have made today?

Mike: The significance of the announcement today is, that there is a huge customer base that is now available to MySQL applications, that we can seamlessly wrap and make available to this community, instead of doing rewriting and re-porting of applications to i5 OS.

Jim: Can I paraphrase?

Mike: Of course!

Jim: If you can't beat'em, join'em!

Seven DB Egos

Kaj: Now we finally have all Egos in place. Let's warm up by a simple, non-provocative question open for anybody on stage: How should a smart developer select a storage engine?

Jim: A smart developer downloads a C++ compiler and starts coding. A lazy developer, who wants to get the job done, well, that's a different question!

Kaj: That's the question I am asking!

Ari: A lazy developer, who doesn't want to code it himself, and doesn't want to wait, can go to our site and download it.

Paul: And I think they just have to look at the matrix that MySQL has of all the storage engines and what one does with them, and match it with their needs.

Mike: Or look at where their data already is.

Ari: Some of this stuff is futureware.

Jim: So let me get something straight here. All of us have written a storage engine, and were all saying "don't do it!"?

Paul: I didn't get asked that question. It's a good thing they have Professional Services at MySQL.

Ari: I want to warn anyone who is contemplating a storage engine, that it's amasingly simple, it looks so easy that you can almost get it going in a week. You can! But the usual 80-20, or even 90-10 rule applies. So the integration / optimisation phase can take some time.

Paul: It's hitting golf balls on the range, and playing with Tiger Woods. It's really tough.

Ari: Putting is the key.

Mikael: The hole is too small.

Jim: I'm glad you brought this up, because I need analogies. I have this discussion with Mårten every two weeks about how long it takes.

Kaj: Monty, you're awfully quiet. How do you think one should do? This room is full of smart developers and smart DBAs. How should they go about identifying the right engine for the right purpose?

Monty: That depends totally on the application. The question is: Are they bound by space or speed? That's the first question. Do they need transactions or not? There are benefits to both, depending on needs.

Monty: There is not a single answer. What you first need is an available, stable engine. And there are lots of us that provide that. Some are still on their way. I don't know how stable DB2 is under MySQL.

Mikael: A smart developer has to know the storage engines. That's the first thing a smart developer has to do. A smart developer knows that they engines are open source, if they don't do what they want them to do, they just go to vi.

Jim: I'm going to disagree, which is unusual for me. The smart developer doesn't have to get it right the first time. He can pick one at random, develop his application, and then move it around until it runs best. And if a new one shows up, he can move it again. That's one of the best things with the Storage Engine architecture. It's just ALTER TABLE, change engine.

Ari: Unfortunately, not all engines are equal, although the API is the same.

Jim: You'll grow up.

Ari: I wish I don't.

Heikki: I have a question to IBM: Is DB2 going to be Open Source?

Mike: I don't think you want it! The DB2 that is embedded in System i has gone through many years of development, and I don't think you want to see it. We do plan to open source the integration layer that maps the storage engine API to the top of the record oriented interface that's inside of System i.

Kaj: So, lets get to be a bit more philosopical. Let's fast forward to 20 years from now, and open up Wikipedia. As you are egos, you look up your own entry in Wikipedia. What do you want to be remembered for, 20 years from now?

Monty: Can I use my ego and a little bit change the question? What I would not like to see is two things: "Monty, author of MySQL, deceased." Or "Monty, the author of the now extinct MySQL Server".

Kaj: I will have to blow the whistle for avoiding the question!

Monty: I couldn't envision this to happen ten years ago, when we started with MySQL. We were doing something good, we wanted to give something back, and thought maybe we would get a couple of consulting gigs. So I don't think I can predict the future. I just hope that I will see the path for the next years, and the path will continue.

Kaj: What would the rest of you want to be remembered for?

Heikki: Well, as you know, Wikipedia runs on InnoDB.

Kaj: And you would want that to still be the case 20 years from now?

Heikki: Yes.

Mikael: Obviously, to be remembered for being a good father to both your children and your brain-children. And hopefully also, to have the first Open Source database company with a billion dollar business.

Jim: Hopefully, I already have a footnote for the BLOB and MVCC. But what I'd really like to be known for is the person who convinced the world's largest and most important and fast open source database that they have to recognise the semantics of the web and learn from the last 10 years of Internet experience and learn to do multi-column, multi-table search. And for a security model that works for the Internet and lots of other good things. Oh yes, and to have a data type that says "this is a string and I don't care how long it is" so we don't have to compromise when computing the length of everybody's last name.

Monty: In other words, you want us to break the SQL standard?

Jim: Oh yes.

Heikki: But Monty, Monty, that's what you did!

Monty: Sure, but Jim always argues that when some things don't work in MySQL, "it's bad because it breaks the standard". Now that I know that he doesn't care about the standard, things should be easier in the future.

Jim: No, it should be standards compliant!

Ari: To continue the Wikipedia round: I went to Wikipedia one night and I was amased to find a list of Swedish speaking Finns (http://en.wikipedia.org/wiki/List_of_Swedish-speaking_Finns). There is a list of that. Monty was on the list. Congratulations! I didn't find Mårten.

Kaj: I think he is there.

Ari: No, no, he wasn't there last night.

Voice from the audience: Well, by now he is!

Ari: I wish there were a list of Finnish speaking Finns, and if there is such as list, I would like to be on that list.

Kaj: That was a complete answer!

Paul: I would like to be recognised as being part of a team that changed what people thought you can do with a relational database. We literally hear this all the time: "You can't do what we need to do with a relational database!". But I say you can, and I'll prove it to you!

Mike: I think we're proof of that. I think we've done that with a database that is embedded into the operating system. Even the TCP/IP configurations are stored in a database. You can do anything relational database that has the appropriate properties.

Mike: My Wikipedia entry? It should write something about my senior PGA career.

Thank you

Kaj: As a referee, I will have to blow the whistle now and say that the match is over. I won't appoint a winner amongst you. The only winner I think that can be appointed is the user. The user can choose the storage engine that best fits the purposes of the application.

Kaj: Having more engines for special purposes, like the last three guys have been introducing here, is good.

Kaj: With all of this I would like all of you guys, except Monty, to leave the stage and continue your fight offline. Monty will join you later.

The Clash concludes to the tunes of Monty Python's Flying Circus.

Photos by James Duncan Davidson 2007