![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
PostgreSQL 8.2 final vs. dev
In this series of articles, we have been using a development version of PostgreSQL 8.2 so far. Although it has never caused us any problems, the final version that has been released in the meantime will undoubtedly become a lot more popular. The difference between the two versions may have been extensively documented in the changelogs, but it is hard to summarize. However, neither performance nor scalability have improved over the past few months. Under a heavy load (up from 25 simultaneous users) there is a 24% decline on average when eight processors are used, and 14% at four processors. The gain that is made when going from four to eight processors has also diminished: while the development version still takes 24%, the final release is barely 6% faster when the number of cores is doubled.
The significant loss of performance first came to light when we tried 8.2-rc1, a near-complete version of the software. As a result of our discovery, the PostgreSQL team quickly released three patches to soothe the pain, but unfortunately, these did not make it into the final release. However, they did land in version 8.2.1. We used the 'final' version 8.2.0, with these specific patches but without any other changes that may have been made for 8.2.1.
Unfortunately, under Solaris things aren't much different. The development version was not doing too well (note that the configuration with eight processors is some 10% slower than the one with four processors), and the picture for the final version isn't any brighter. This was a dilemma: PostgreSQL 8.2 final will be used much more often than 8.2-dev, but does a worse job at using the hardware well. So as not to misrepresent the server unnecessarily, and because we have already collected a lot of material using 8.2-dev, we figured we might as well continue for now to use it as a basis.
A less serious version problem occurred with MySQL, of which version 4.1.22 turned out to be about 10% slower than 4.1.20, which rules out the possibility of direct comparisons.
The significant loss of performance first came to light when we tried 8.2-rc1, a near-complete version of the software. As a result of our discovery, the PostgreSQL team quickly released three patches to soothe the pain, but unfortunately, these did not make it into the final release. However, they did land in version 8.2.1. We used the 'final' version 8.2.0, with these specific patches but without any other changes that may have been made for 8.2.1.
Unfortunately, under Solaris things aren't much different. The development version was not doing too well (note that the configuration with eight processors is some 10% slower than the one with four processors), and the picture for the final version isn't any brighter. This was a dilemma: PostgreSQL 8.2 final will be used much more often than 8.2-dev, but does a worse job at using the hardware well. So as not to misrepresent the server unnecessarily, and because we have already collected a lot of material using 8.2-dev, we figured we might as well continue for now to use it as a basis.
A less serious version problem occurred with MySQL, of which version 4.1.22 turned out to be about 10% slower than 4.1.20, which rules out the possibility of direct comparisons.
Next page (Scaling behaviour from 4 to 8 sockets - 6/10)
