Re: pg_migrator and an 8.3-compatible tsvector data type

From: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <stark(at)enterprisedb(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Teodor Sigaev <teodor(at)sigaev(dot)ru>
Subject: Re: pg_migrator and an 8.3-compatible tsvector data type
Date: 2009-05-29 12:58:45
Message-ID: 4A1FDC05.4040104@kaltenbrunner.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zdenek Kotala 2009-05-29 13:27:34 Re: pg_migrator and an 8.3-compatible tsvector data type
Previous Message Zdenek Kotala 2009-05-29 12:44:12 Re: Compiler warning cleanup - unitilized const variables, pointer type mismatch