Re: Formatting Curmudgeons WAS: MMAP Buffers

On Thu, Apr 21, 2011 at 11:48 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On Thursday, April 21, 2011 05:43:16 PM Robert Haas wrote:
>> On Thu, Apr 21, 2011 at 11:37 AM, Ross J. Reedstrom <reedstrm(at)rice(dot)edu>
> wrote:
>> > On Thu, Apr 21, 2011 at 11:16:45AM -0400, Tom Lane wrote:
>> >> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> >> > I agree.  I am in favor of a shorter release cycle.
>> >> I'm not.  I don't think there is any demand among *users* (as opposed to
>> >> developers) for more than one major PG release a year.  It's hard enough
>> >> to get people to migrate that often.
>> > In fact, I predict that the observed behavior would be for even more end
>> > users to start skipping releases. Some already do - it's common not to
>> > upgrade unless there's a feature you really need, but for those who do
>> > stay on the 'current' upgrade path, you'll lose some who can't afford to
>> > spend more than one integration-testing round a year.
>> Well, that aspect of the problem doesn't bother me, much.  I don't
>> really care whether people upgrade to each new release the moment it
>> comes out anyway.
>> Not to say that there aren't OTHER problems with the idea...
> One could argue that its causing bad PR for postgres. I have seen several
> parties planning to migrate away or not migrate to postgres because of
> performance evaluations they made. With 7.4, 8.0 and 8.2. In 2010.

That's certainly true. It's clearly insane to benchmark with anything
other than the latest major release - on any product - if you want to
have any pretense of fairness. However, for users who have
applications that work and perform acceptably, I don't think it
benefits us to be too aggressive in trying to get them onto a later
major release. If we wanted to do that, we could maintain
back-branches for two years instead of five, but I don't think that
would be doing anyone any favors.

In fact, I've been wondering if we shouldn't consider extending the
support window for 8.2 past the currently-planned December 2011.
There seem to be quite a lot of people running that release precisely
because the casting changes in 8.3 were so painful, and I think the
incremental effort on our part to extend support for another year
would be reasonably small. I guess the brunt of the work would
actually fall on the packagers. It looks like we've done 5 point
releases of 8.2.x in the last year, so presumably if we did decide to
extend the EOL date by a year or so that's about how much incremental
effort would be needed.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company