Drupal 7 and PostgreSQL

I am in the midst of preparing for my tutorial, Realistic Load Testing, at PGCon 2010. After talking with a number of folks at my favorite IRC channel, I decided to use the Drupal 7 Project as my test case.
For years, Drupal worked best with MySQL. Not that I harbor ill will against the database, it is just my experience with databases has led me to PostgreSQL as a superior engine. That said, MySQL works great for these types of applications. The types of applications we do at Digitec tend to need a much more robust solution.
With Drupal 7, there has been a more concerted effort in giving PostgreSQL a chance at being a valid alternative to MySQL. The code changes and the model the Drupal development team has made have helped.
My hope is that by using Drupal, I will not only give a good "real world" example application, but also give back to the Open Source community through the tests and tools that will be created for the tutorial. As Drupal 7 is still in beta development, I hope these tests can help the developers look into solutions for any problems that occur. I also hope that it will help in showing that PostgreSQL is a great fit for Drupal.

HOWTO setup pgBouncer on Debian Part 1

When looking to provide database connections under a steady (or heavy) load, you will likely need to look into a database connection pooler. There are a number of good options for PostgreSQL such as pgBouncer, pgpool-II, SQL Relay, and a few others.
My personal favorite as of late is pgBouncer. Here's a few reasons why I like it:

• a lightweight connection pooler--it is designed solely for pooling
• low resource requirement
  
• written with Python (a lot of our inernal apps use Python, so interoperability is great to have)
• supports online restart/upgrade without dropping client connections

When setting up a pooler, you will want to have a separate server just for the pooler. Adding a pooler to the same server as the database only degrades the performance of PostgreSQL, so make sure you don't.

I use Debian as my choice of Linux distro. Unfortunately, there isn't an official package to install on Lenny. However, thanks to good ol' backports, we can find an up-to-date package. First things first, add backports to your /etc/apt/sources.list by adding the following source:
deb http://www.backports.org/debian lenny-backports main contrib non-free

Next, you will want to do aptitude update (or apt-get update)

You can learn more about how to use backports on their instructions page.

Finally, here's how to do an install of pgBouncer:
$ aptitude -t lenny_backports install pgbouncer

EXPLAIN ANALYZE is Your Friend

EXPLAIN ANALYZE is a useful tool to help see what query plan the planner creates for any query. One tool that I have found useful for some time is depesz's online tool, http://explain.depesz.com/. Simply "paste your explain analyze plan, and see the output."

PGCon 2010 Schedule and Registration Now Open!

According to Dan Langille's blog, the schedule and registration page is now up for PGCon 2010 held in Ottowa, Canada! I will be giving a tutorial on "Realistic Load Testing." I hope to see you there.

PGBouncer or PGPool II? That is the question!

We have been trying out both PgBouncer and pgpool II for connection pooling in front of our Postgresql database servers. One of the issues we are trying to tackle is how to make PgBouncer HA (High Availability) and if it matters.
pgpool II already has the ability to be HA using pgpool-HA, but pgpool is also a more featureful application that does much more than simple connection pooling.
On the other hand, PgBouncer is a nice, lightweight connection pooler that we have found to fit the bill rather well. Our question is, if we have auto-failover set up in our private cloud for PgBouncer, is there a need to be HA? What would need to be done? If we forgo making the pooler HA, what risks do we pose?
All these and other questions are going through my head. Any suggestions?

PGBouncer and Database Updates

I have been using pgBouncer for a while and have run into a need in our development server to drop and recreate a database. I have had issues in the past with trying to PAUSE, but that ends up stopping all connections, which isn't always a feasible option. I have found that simply commenting out the database in question in the pgbouncer.ini file and simply doing a RELOAD. This will also kill any clients currently connected to that database and allow you to drop/recreate. After making changes, simply uncomment and RELOAD again.