Tory M Blue wrote:
I'm doing an OS upgrade and have been sitting on 8.4.3 for sometime. I was wondering if it's better for the short term just to bring things to 8.4.4 and let 9.0 bake a bit longer, or are people with large data sets running 9.0 in production already?
I'm aware of two people with large data sets who have been running 9.0 in production since it was in beta. Like most code, what you have to consider is how much the code path you expect to use each day has been modified during the previous release. If you're using 9.0 as "a better 8.4", the odds of your running into a problem are on the low side of the risk curve. But those using the features that are both new and were worked on until the very end of the development cycle, like the new replication features, they are much more likely to run into a bug.
There are two main things I've been advising clients to be very careful about when considering an early 9.0 upgrade mainly as a straight replacement for 8.4 (making it possible to start testing the replication stuff too, but not relying on that immediately). The changes to acceptable PL/pgSQL syntax can easily break some existing procedures; easy to fix if you find them in testing, but you if you have a lot of functions in that language you should really do a code audit along with testing.
The other is that query plans are much more likely to use Materialize nodes now in ways they never did before. That planning change will be long-term positive, but I expect to see some short-term performance regressions in plans that used to work better; not because of the code itself, just because of Murphy's Law. This is similar to how the hash aggregation changes made to 8.4 could produce worse plans under unexpected circumstances than what people saw in 8.3 and earlier, which is something else you're also exposed to here if your existing code is running on 8.4. There are less of those situations in the recent 8.4 releases than the early ones, but the possibility of aggressive hashing being worse than the older approach still happens. I've seen exactly one of them on a production server running 8.4, and the problem had already been reported to the relevant list before I got there.
-- Greg Smith, 2ndQuadrant US greg@xxxxxxxxxxxxxxx Baltimore, MD PostgreSQL Training, Services and Support www.2ndQuadrant.us Author, "PostgreSQL 9.0 High Performance" Pre-ordering at: https://www.packtpub.com/postgresql-9-0-high-performance/book -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
