Whether or not you made it our CHAR(10) conference last month, you can now relive part of the experience by downloading the conference slides. Some of those were posted live during the conference, some showed up later, but almost everything is there now. Sadly, Nic Ferrier's entertaining presentation about how WooMe was scaled up using Londiste and Django wasn't available in a form we could easily replay. For that one, you certainly did have to be there, in more ways than one.
The two talks I found the most informative were the updates on the states of pgpool-II and pgmemcache. Both those tools have that slightly frustrating combination of being really useful and a bit underdocumented relative to how complicated they are (in English at least!), so getting additional insight into them from
Officially Greenplum Database Single Node Edition (SNE) is only installable on Red Hat Enterprise Linux (RHEL) and SUSE Linux Enteprise Server (SLES), but while surfing the web I have seen many requests on how to install it on Debian/Ubuntu. Here I'm trying to give you some advices.
One of the main reasons users switch from other relational databases to PostgreSQL is the advanced support for geographic objects included in the PostGIS extension.
Being PostgreSQL specialists at 2ndQuadrant, we have tried to investigate if it was possible (and how) to install PostGIS on the Greenplum Single Node edition. Let's see how Marco Nenciarini, 2ndQuadrant consultant and a long time Debian developer, tried to do it.
Last week at the CHAR(10) conference we had a workshop on "Cloud Databases". To put it simply: what to do when the use case requirements exceed the resources available in the database server.
This was a main topic of the whole conference, and several solutions have been illustrated during the day. A common theme has been that no solution fits all the use cases, and that each solution comes with its cost; hence you have to choose the solution that your use case can afford.
This week I did something I'd prefer to never repeat: I left the country, did something useful, and made it back again in the same day. The occasion was the FreeBSD Developer Summit, held just before BSDCan--the convention that happens in Ottawa the week before PGCon every year. So I get to head right back again next week, but stay a while that time.The FreeBSD developers were nice enough to sponsor my trip so that we could talk about both the business and technical hurdles that I felt were keeping the sort of companies I work with from deploying their databases on FreeBSD more often than they do. My slightly updated slides are available on our talks page, I cleaned up a couple of things from what was presented (the most important rewording I'll talk about below).I
If you have a Linux server of the RedHat family (inclusing CentOS and Fedora), you might envy the way Debian/Ubuntu distributions handle PostgreSQL clusters management.
Although it is not easy to install different PostgreSQL versions on the same RedHat Linux server using RPMs, it is much simpler to install several instances of PostgreSQL (servers) and, at the same time, take advantage of the services infrastructure.
If you're running Linux, and particularly if you're running a database on Linux, it's been hard to recommend any filesystem other than plain old ext3 in recent years. Some of the alternatives that looked interesting at one point--jfs, ReiserFS--are completely abandoned at this point. The one that has been almost viable for some time now is XFS, originally an SGI projecs. And it's back to being in the limelight again this week.XFS had suffered from a number of problems in the past. Since it was designed for stable hardware, it wasn't as robust on standard cheap PC hardware at first; quite a bit of that was just cleaned up two years ago. It had this odd problem with zeroed files that scared some people off. It was treated as a second-class citizen in
A few weeks ago I presented an updated 2010 version of my talk on database hardware benchmarking at PG East; slides available from our talks page. CPU and memory performance are particularly important for a PostgreSQL database, because every individual query runs as a single process. Therefore, the speed of your fastest core determines how fast any one query can execute at, and in modern systems that's quite likely to bottleneck based on memory speed.One of the things that's obvious from recent memory speed results is that all of AMD's processors have been stuck in a distant second place for almost 18 months now. While AMD continues to use DDR2-800, Intel's "Nehalem" processors, shipping in volume since early 2009, have been adopting increasingly fast DDR3 in good
and uses PostgreSQL.
In order to do this, I need a multi-CPU environment. While still waiting to get our new servers installed here in our data centre in Italy, I decided to look at Amazon's Elastic Compute Cloud (EC2) infrastructure. My intention is to do some benchmarking and spot the main differences in terms of performances between Greenplum Single Node Edition
and PostgreSQL 8.4
, my favourite DBMS.
If you wish to follow this article, you need to have an Amazon AWS account with a valid credit card. Do not worry, this test will only cost you a couple of dollars!
I have been thinking for a while now about adding Greenplum support to an open-source application for web analytics that I wrote a few years ago, which is called
Today is the deadline for the special room rate at the hotel hosting this month's PostgreSQL Conference East 2010. If you've been procrastinating booking a spot at the conference, as of tomorrow that will start costing you.My talk is on Database Hardware Benchmarking and is scheduled for late afternoon on the first day, Thursday March 25th. Those who might have seen this talk before, either live at PGCon 2009 or via the video link available there, might be wondering if I'm going to drag out the same slides and talk again. Not the case; while the general philosophy of the talk ("trust no one, run your own benchmarks") stays the same, the examples and test mix suggested have been updated to reflect another year worth of hardware advances, PostgreSQL work, and my own