Thread: Selling an 8.1 to 8.3 upgrade
I've been asked to put together a list of reasons to upgrade a db from 8.1 to 8.3 and I've looked over the changelog, but they want a bullet list of 4-5 top things. I'm curious what others would say the most 5 important updates from 8.1 to 8.3 are. I can say "performance improvevents" but I'm not sure how to sell that better other than listing what's in the release notes. I also think the autovac was greatly improved in these releases as well? Or maybe I'm thinking 8.0 to 8.1? Sorry this is so vague, I'm frustrated with this request as I figured just the amount of bug-fixes alone would be adequate reasoning. Thanks, Josh
pg 8.1.4 has a very ugly bug which prevents VACUUM and AUTOVACUUM from performing well.... I certain situations the AUTOVACUUM will start failing and any VACUUM operations will fail too. solution I found was to periodically REINDEX my tables and INDEXES. the major effect of this bug is Pg starts continuously taking up filesystem space for nothing.... pg looses track of disk space that is no longer needed and simply requests more and more; another side effect is that, in that situation, query execution time grows continuously too.... until client applications simply tiemout. This issue is documented and has been fixed starting Pg 8.1.6. JOao On Fri, 2009-04-24 at 12:01 -0500, Josh Trutwin wrote: > I've been asked to put together a list of reasons to upgrade a db > from 8.1 to 8.3 and I've looked over the changelog, but they want a > bullet list of 4-5 top things. I'm curious what others would say the > most 5 important updates from 8.1 to 8.3 are. > > I can say "performance improvevents" but I'm not sure how to sell > that better other than listing what's in the release notes. I also > think the autovac was greatly improved in these releases as well? Or > maybe I'm thinking 8.0 to 8.1? > > Sorry this is so vague, I'm frustrated with this request as I figured > just the amount of bug-fixes alone would be adequate reasoning. > > Thanks, > > Josh >
On Fri, 2009-04-24 at 12:01 -0500, Josh Trutwin wrote: > I've been asked to put together a list of reasons to upgrade a db > from 8.1 to 8.3 and I've looked over the changelog, but they want a > bullet list of 4-5 top things. I'm curious what others would say the > most 5 important updates from 8.1 to 8.3 are. What is the reason that you want to upgrade? Do you have a particular problem you are trying to solve? Are there improvements for developers that you think will be beneficial, or are you simply wanting to upgrade from a 4.5 year old DB platform? You'll probably have the best luck if you sell it based on pains that you are facing, improvements that can be made, or money that can be saved. > I can say "performance improvevents" but I'm not sure how to sell > that better other than listing what's in the release notes. I also > think the autovac was greatly improved in these releases as well? Or > maybe I'm thinking 8.0 to 8.1? Are you experiencing performance issues, or do you have reason to suspect you will? Performance improvements are great if you need them. It can be a hard sell to business folks though when things are performing just fine. > Sorry this is so vague, I'm frustrated with this request as I figured > just the amount of bug-fixes alone would be adequate reasoning. Unfortunately, what seems adequate to us technical folks is seldom is to the business folks. -- Brad Nicholson 416-673-4106 Database Administrator, Afilias Canada Corp.
On Fri, Apr 24, 2009 at 11:01 AM, Josh Trutwin <josh@trutwins.homeip.net> wrote: > I've been asked to put together a list of reasons to upgrade a db > from 8.1 to 8.3 and I've looked over the changelog, but they want a > bullet list of 4-5 top things. I'm curious what others would say the > most 5 important updates from 8.1 to 8.3 are. There were a lot of improvements from 8.1 to 8.3. For the system at work, the compelling ones were: HOT updates. General improvements in the query planner. This has been true for nearly every new major release. Improved vacuuming, including multi-threaded vacuum capability. Concurrent index creation. Improved handling of joins Fillfactor setting Much improved checkpointing Changes to the buffering methods so large seq scans don't evict more popular data from the buffers. This is much more important than it sounds. The differences add up to being huge for us. Our database servers are quite beefy, but they'd be working a LOT harder under 8.1 than they do under 8.3
Thanks for all the replies, I'm picking this one to reply to. Winner! On Fri, 24 Apr 2009 13:40:29 -0400 Brad Nicholson <bnichols@ca.afilias.info> wrote: > On Fri, 2009-04-24 at 12:01 -0500, Josh Trutwin wrote: > > I've been asked to put together a list of reasons to upgrade a db > > from 8.1 to 8.3 and I've looked over the changelog, but they want > > a bullet list of 4-5 top things. I'm curious what others would > > say the most 5 important updates from 8.1 to 8.3 are. > > What is the reason that you want to upgrade? Do you have a > particular problem you are trying to solve? Are there improvements > for developers that you think will be beneficial, or are you simply > wanting to upgrade from a 4.5 year old DB platform? We manage about 12 different boxes, 10 of the 12 are on 8.3, the other two 8.1 with this being one of them, the other one is scheduled for upgrade when new h/w arrives. _Our_ reasons are supporting one platform at a time, updates to the PL language, COPY TO from SELECT, improvements to performance (less "why is this so slow?" questions are always good). What prompted this was someone checked in a change that used JUSTIFY_INTERVAL in a query and that crunked on 8.1 so we tried to get the 8.3 upgrade ball rolling and were met with the list of demands. :) These replies and more going over the changelogs helped me add more evidence to push for the upgrade. Thanks, Josh
On Fri, 24 Apr 2009, Scott Marlowe wrote: > Improved vacuuming, including multi-threaded vacuum capability. That's multi-process vacuum capability; don't you know you can't use the T-word on these lists? Scott's list is similar to the one I'd come up. To summarize the main items on there, the thing to realize is that 8.1 databases are prone to falling into all sorts of long-term maintenance traps: autovacuum, indexes, checkpoints, and degraded plans can all cause issues that are really hard to resolve on that version. Performance is always better on 8.3, and there's several classes of holes you can fall into with older versions that are either resolved or have useful workarounds now. If your database gets big or the load heavy, you're guaranteed to fall into at least one of them eventually. http://www.postgresql.org/about/featurematrix should also provide you some ideas for features you might find useful in the newer version. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
On Fri, 24 Apr 2009 13:03:06 -0600 Scott Marlowe <scott.marlowe@gmail.com> wrote: > On Fri, Apr 24, 2009 at 11:01 AM, Josh Trutwin > <josh@trutwins.homeip.net> wrote: > > I've been asked to put together a list of reasons to upgrade a db > > from 8.1 to 8.3 and I've looked over the changelog, but they > > want a bullet list of 4-5 top things. I'm curious what others > > would say the most 5 important updates from 8.1 to 8.3 are. > > There were a lot of improvements from 8.1 to 8.3. For the system > at work, the compelling ones were: > HOT updates. > General improvements in the query planner. This has been true for > nearly every new major release. > Improved vacuuming, including multi-threaded vacuum capability. > Concurrent index creation. > Improved handling of joins > Fillfactor setting > Much improved checkpointing > Changes to the buffering methods so large seq scans don't evict > more popular data from the buffers. This is much more important > than it sounds. For me the reason to switch was the inclusion of the great work by Oleg and Teodor: Full-text search into core. It looks like 8.4 is going to be a great release too and I think it will be an enough cool reason to switch not only DB release but OS release as soon as 8.4 end up in the backport of Lenny. -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Fri, Apr 24, 2009 at 1:01 PM, Josh Trutwin <josh@trutwins.homeip.net> wrote: > I've been asked to put together a list of reasons to upgrade a db > from 8.1 to 8.3 and I've looked over the changelog, but they want a > bullet list of 4-5 top things. I'm curious what others would say the > most 5 important updates from 8.1 to 8.3 are. > > I can say "performance improvevents" but I'm not sure how to sell > that better other than listing what's in the release notes. I also > think the autovac was greatly improved in these releases as well? Or > maybe I'm thinking 8.0 to 8.1? > Sorry this is so vague, I'm frustrated with this request as I figured > just the amount of bug-fixes alone would be adequate reasoning. It's not. There are probably more people using 8.1 than 8.3 and 8.1 has had more time to mature. From bug fix perspective, it's probably better (aside from some 'broken design' bugs that couldn't be backpatched, like plan invalidation). I hate to be the rain cloud here, but you need to sell yourself before you sell your decision makers. What are you looking for in the newer releases that will help you write software faster, better, and cleaner? That is, what are _you_ looking for? merlin
Merlin Moncure <mmoncure@gmail.com> writes:
> On Fri, Apr 24, 2009 at 1:01 PM, Josh Trutwin <josh@trutwins.homeip.net> wrote:
>> Sorry this is so vague, I'm frustrated with this request as I figured
>> just the amount of bug-fixes alone would be adequate reasoning.
> It's not. There are probably more people using 8.1 than 8.3 and 8.1
> has had more time to mature. From bug fix perspective, it's probably
> better (aside from some 'broken design' bugs that couldn't be
> backpatched, like plan invalidation).
That's a fair point, but *only* if the 8.1 installation in question is
reasonably up to date. If you're running something like 8.1.4 then
you're short several years of bug fixes, and it becomes much less
clear that what you've got is less buggy than 8.3.recent.
It would be interesting sometime to gather statistics on how far back
bug fixes tend to go in released branches. My sense of it is that
there's quite a large fraction that have to go back more than one
branch; but I have no numbers to back this up.
(The point is fresh in mind since I'm busy right now fixing an
aggregate/subselect bug that dates back to 7.4.)
regards, tom lane
On Sat, Apr 25, 2009 at 11:28 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Merlin Moncure <mmoncure@gmail.com> writes: >> On Fri, Apr 24, 2009 at 1:01 PM, Josh Trutwin <josh@trutwins.homeip.net> wrote: >>> Sorry this is so vague, I'm frustrated with this request as I figured >>> just the amount of bug-fixes alone would be adequate reasoning. > >> It's not. There are probably more people using 8.1 than 8.3 and 8.1 >> has had more time to mature. From bug fix perspective, it's probably >> better (aside from some 'broken design' bugs that couldn't be >> backpatched, like plan invalidation). > > That's a fair point, but *only* if the 8.1 installation in question is > reasonably up to date. If you're running something like 8.1.4 then > you're short several years of bug fixes, and it becomes much less > clear that what you've got is less buggy than 8.3.recent. > > It would be interesting sometime to gather statistics on how far back > bug fixes tend to go in released branches. My sense of it is that > there's quite a large fraction that have to go back more than one > branch; but I have no numbers to back this up. > > (The point is fresh in mind since I'm busy right now fixing an > aggregate/subselect bug that dates back to 7.4.) My first thought would be to poll the website. This might lead to bad representative sample though...the people who check the website frequently are more likely to be hip and up to the latest version. Maybe pull some redhat strings and see whats going on with the server distros? They might have some stats on how many pg rpms are out there. I'd venture to say a lot of poeple stick with what's ever provided with the o/s. merlin