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

From Bruce Momjian
Subject Re: pg_migrator and an 8.3-compatible tsvector data type
Date
Msg-id 200905282353.n4SNrkI10915@momjian.us
Whole thread Raw
In response to Re: pg_migrator and an 8.3-compatible tsvector data type  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: pg_migrator and an 8.3-compatible tsvector data type  (Greg Stark <stark@enterprisedb.com>)
Re: pg_migrator and an 8.3-compatible tsvector data type  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
Alvaro Herrera wrote:
> Tom Lane wrote:
> 
> > People who want decent performance on partial match queries (or maybe
> > even *any* TS queries) are going to have to convert to the new format
> > anyway, though, so maybe this isn't something worth putting a whole lot
> > of work into.  It might be sufficient if the database conversion
> > succeeds but leaves the tsvector columns unusable until they're
> > converted.
> 
> 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.  I think
doing a backup, then using --link mode will be the most common usage
pattern.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Python 3.0 does not work with PL/Python
Next
From: Bruce Momjian
Date:
Subject: Re: pg_migrator and an 8.3-compatible tsvector data type