Re: Formatting Curmudgeons WAS: MMAP Buffers

On 05/09/2011 12:06 PM, Andrew Dunstan wrote:
> The fact that we can do in place upgrades of the data only addresses 
> one pain point in upgrading. Large legacy apps require large retesting 
> efforts when upgrading, often followed by lots more work renovating 
> the code for backwards incompatibilities. This can be a huge cost for 
> what the suits see as little apparent gain, and making them do it more 
> frequently in order to stay current will not win us any friends.

I just had a "why a new install on 8.3?" conversation today, and it was 
all about the application developer not wanting to do QA all over again 
for a later release.

Right now, one of the major drivers for "why upgrade?" has been the 
performance improvements in 8.3, relative to any older version.  The 
main things pushing happy 8.3 sites to 8.4 or 9.0 that I see are either 
VACUUM issues (improved with partial vacuum in 8.4) or wanting real-time 
replication (9.0).  I predict many sites that don't want either are 
likely to sit on 8.3 for a really long time.  The community won't be 
able to offer a compelling reason why smaller sites in particular should 
go through the QA an upgrade requires.  The fact that the app QA time is 
now the main driver--not the dump and reload time--is good, because it 
makes it does make it easier for the people with the biggest data sets 
to move.  They're the ones that need the newer versions the most anyway, 
and in that regard having in-place upgrade start showing up as of 8.3 
was really just in time.

I think 8.3 is going to be one of those releases like 7.4, where people 
just keep running it forever.  At least shortening the upgrade path has 
made that concern a little bit better.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us