Re: pg_migrator and an 8.3-compatible tsvector data type - Mailing list pgsql-hackers

From Stefan Kaltenbrunner
Subject Re: pg_migrator and an 8.3-compatible tsvector data type
Date
Msg-id 4A1FDC05.4040104@kaltenbrunner.cc
Whole thread Raw
In response to Re: pg_migrator and an 8.3-compatible tsvector data type  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>> Alvaro Herrera wrote:
> 
>>> There are so many caveats on pg_migrator (and things that need to be
>>> done after the migration is complete) that one starts to wonder if
>>> people is not better off just using parallel pg_restore.  From Stefan's
>>> reported timings I'm not sure that pg_migrator is that much of a benefit
>>> in the first place ... unless copy mode can be made much faster.  (On
>>> link mode it is so much faster that it's worth it, but then you don't
>>> have an escape hatch).
>> That is accurate.  I doubt copy mode speed can be improved.
> 
> Why not?  Right now it's single-threaded.  Would it be faster if it ran
> several copies in parallel?

I guess it would be much faster on powerful hardware - we also have to 
consider that copy mode now is a no-op really.
If it had to do any actual page conversation too it seems entirely 
possible that a parallel restore might be even faster that a single 
threaded pg_migrator in copy mode.


Stefan


pgsql-hackers by date:

Previous
From: Zdenek Kotala
Date:
Subject: Re: Compiler warning cleanup - unitilized const variables, pointer type mismatch
Next
From: Zdenek Kotala
Date:
Subject: Re: pg_migrator and an 8.3-compatible tsvector data type