Skip site navigation (1) Skip section navigation (2)

Re: pg_migrator and an 8.3-compatible tsvector data type

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: 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-28 23:53:46
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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

  Bruce Momjian  <bruce(at)momjian(dot)us>

  + If your life is a hard drive, Christ can be your backup. +

In response to


pgsql-hackers by date

Next:From: Greg StarkDate: 2009-05-28 23:56:31
Subject: Re: pg_migrator and an 8.3-compatible tsvector data type
Previous:From: Bruce MomjianDate: 2009-05-28 23:36:20
Subject: Re: Python 3.0 does not work with PL/Python

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group