Re: pg_migrator to /contrib in a later 9.0 beta

On 2010-05-06 01:45, Bruce Momjian wrote:
> Jesper Krogh wrote:
>    
>> On 2010-05-03 23:09, Bruce Momjian wrote:
>>      
>>> Robert Haas wrote:
>>>
>>>        
>>>> On Sun, May 2, 2010 at 3:45 PM, Dimitri Fontaine<dfontaine@hi-media.com>   wrote:
>>>>
>>>>          
>>>>> Now you tell me how awful this idea really is :)
>>>>>
>>>>>            
>>>> I'm not sure I can count that high.  :-)
>>>>
>>>>          
>>> While I can't improve on Robert's reply, I can supply a PDF about how
>>> pg_migrator works:
>>>
>>>     http://momjian.us/main/presentations/technical.html#pg_migrator
>>>
>>>
>>>        
>> There is a huge amount of users to whom pg_migrator is "at least"
>> a big a feature as HS+SR is.
>>
>> Last dump/restore was a 24 hours process in one of our installations.
>> I think it was due to in-efficiency in handling BYTEA types in the
>> process (but not sure).
>>
>> But I'm one of the few guys who seem to have an infinite amount of
>> time for reading on mailing lists, but without my knowledge from
>> reading this list I would never have run pg_migrator on my production
>> data if I had to pick it from pg_foundry.
>>      
> So, did you use "copy" or "link" mode, and how fast was the pg_migrator
> upgrade?
>
>    
I did go the painful way (dump+restore) at that point in time.
It was an 8.1 - 8.3 migration. Since then data has grown and the dump
restore is even less favorable on the 8.3 -> 9.0 migration.

So in general the pg_migrator way seems to be the only way to aviod
the slony way which is orders of magnitude more complicated.

Q: I read you pdf, why isn't statistics copied over? It seems to be the last
part missing from doing an upgrade in a few minutes.

Jesper
-- 
Jesper