Re: State of Beta 2

Kaare Rasmussen <kar@kakidata.dk> writes:
>> "interesting" category.  It is in the category of things that will only
>> happen if people pony up money to pay someone to do uninteresting work.
>> And for all the ranting, I've not seen any ponying.

> Just for the record now that there's an argument that big companies need 24x7
> - could you or someone else with knowledge of what's involved give a
> guesstimate of how many ponies we're talking. Is it one man month, one man
> year, more, or what?

Well, the first thing that needs to happen is to redesign and
reimplement pg_upgrade so that it works with current releases and is
trustworthy for enterprise installations (the original script version
depended far too much on being run by someone who knew what they were
doing, I thought).  I guess that might take, say, six months for one
well-qualified hacker.  But it would be an open-ended commitment,
because pg_upgrade only really solves the problem of installing new
system catalogs.  Any time we do something that affects the contents or
placement of user table and index files, someone would have to figure
out and implement a migration strategy.

Some examples of things we have done recently that could not be handled
without much more work: modifying heap tuple headers to conserve
storage, changing the on-disk representation of array values, fixing
hash indexes.  Examples of probable future changes that will take work:
adding tablespaces, adding point-in-time recovery, fixing the interval
datatype, generalizing locale support so you can have more than one
locale per installation.

It could be that once pg_upgrade exists in a production-ready form,
PG developers will voluntarily do that extra work themselves.  But
I doubt it (and if it did happen that way, it would mean a significant
slowdown in the rate of development).  I think someone will have to
commit to doing the extra work, rather than just telling other people
what they ought to do.  It could be a permanent full-time task ...
at least until we stop finding reasons we need to change the on-disk
data representation, which may or may not ever happen.

            regards, tom lane