Tom,
> If such a tool were available, I don't think it'd be hard to get
> consensus on organizing our releases so that it were applicable more
> often than not. We could postpone changes that would affect user
> table contents until we'd built up a backlog that would all go into
> one release. E
Ühel kenal päeval, K, 2006-02-08 kell 15:51, kirjutas Tom Lane:
> Josh Berkus writes:
> >> This would be a very fine project for someone to pick up (maybe one of
> >> the corporate supporters could sponsor someone to work on it?)
>
> > We looked at it for Greenplum but just couldn't justify putt
Josh Berkus writes:
>> This would be a very fine project for someone to pick up (maybe one of
>> the corporate supporters could sponsor someone to work on it?)
> We looked at it for Greenplum but just couldn't justify putting it near
> the top of the priority list. The work/payoff ratio is ter
On Feb 8, 2006, at 12:55 PM, Josh Berkus wrote:
Andrew,
This would be a very fine project for someone to pick up (maybe
one of the corporate supporters could sponsor someone to work on it?)
We looked at it for Greenplum but just couldn't justify putting it
near the top of the priority li
On Wed, 2006-02-08 at 11:55 -0800, Josh Berkus wrote:
> One justification for in-place upgrades is to be faster than
> dump/reload. However, if we're assuming the possibility of new/modified
> header fields which could then cause page splits on pages which are 90%
> capacity, then this time sa
Andrew,
This would be a very fine project for someone to pick up (maybe one of
the corporate supporters could sponsor someone to work on it?)
We looked at it for Greenplum but just couldn't justify putting it near
the top of the priority list. The work/payoff ratio is terrible.
One justifi
