Introduction

I have always been a keeper of engineering notebooks and this blog serves as an evolution of them. My Dad used to keep a notebook and I remember asking him about it when I was young. He told me it was easier to put all of his notes in one place than it was to keep track of a bunch of pieces of paper scattered over his desk. That made sense to me. My Dad wasn't an engineer but he did start his career selling computers to them.

When I got to college and started studying Electrical Engineering, my professors had me create notebooks for each of my classes. They had specific formats for all students to follow and they drilled it into us that our employers would require us to keep notebooks. Furthermore the professors indicated our employers would ask to keep those notebooks when we left for other opportunities. I made sure to ask for a notebook when I started at Oracle Corporation fresh out of college. Then I made sure to keep detailed notes of everything I did. I also noticed that I was the only one with a notebook. When my group got spun out into another company, nobody asked for my notebooks. Nobody asked for them when I left that company to head out on my own to do consulting. In fact, I have 20 years of notebooks full of wonderful information. Some of it is dated, of course, but there is also a lot of useful information.

About the same time I left Oracle's spin-off, I discovered PostgreSQL. While at Oracle, it made sense that any time you needed a database, you would use Oracle. There were no license fees to worry about and so it was like free software. When I left to do my own consulting, I discovered that Oracle wasn't free. In fact it was rather expensive. Not everyone could afford it and so I looked for another solution. At that time, there were 2 possible open source databases: MySQL and PostgreSQL. MySQL was for small projects and PostgreSQL was for larger ones. Coming from Oracle, I decided to learn PostgreSQL and found it to be amazingly similar. It wasn't exactly the same but it had a lot of the same features.

Fast forward a few years and in 2005 I saw an article about a new company called EnterpriseDB that wanted to take PostgreSQL and make it look like Oracle for less money. I had the same idea years earlier and even started talking with several venture capitalists who were willing to fund it. Instead of trying to compete with EnterpriseDB, I decided to work with them and became one of their first employees.

Working at EnterpriseDB was a lot of fun. It was a small company and reminded a little bit of Oracle when I worked for them in high school. There was a lot of energy and we all thought that anything was possible. The whole time I was there, I continued to keep detailed notebooks of all the technical issues I was solving.

Eventually I found myself working for one of EnterpriseDB's customers and my technical knowledge of PostgreSQL continued to grow. While I had once been an Oracle expert, I now found myself favoring PostgreSQL. Now I work for a large video game company and we use PostgreSQL extensively.

A few days ago I was going through my notebook and my boss commented that I should write a book. I have done that before and felt like it was too little reward for such a huge effort. Before I could express this to him, he suggested that I start a blog and compile all of my PostgreSQL technical notes in one place. Then others looking for solutions to problems that I have already solved will be edified. So it is with that thought that I have created this blog.

It is not my intent to have this blog replace PostgreSQL's own excellent documentation. I actually plan to reference it extensively. Instead it is my hope that entries from my own engineering notebooks will help further explain difficult topics and provide another example for PostgreSQL developers to follow.

One downside to a blog instead of writing a book is that I have to act as my own editor. I will try to do a good initial job but mistakes will be made. Please be patient and politely let me know of any typos or wording that isn't quite clear. I will do my best to fix things in a timely manner. I will also make sure to verify all code examples and SQL statements to make sure they work as advertised.