Re: pg_migrator and an 8.3-compatible tsvector data type

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, 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 18:44:22
Message-ID: 22236.1243622662@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> It would be nice to have pg_migrator handle this, especially if we could
> do it in parallel. Then we just have to warn users that migrating a
> database with tsvector columns takes significantly longer. That is,

> 1) do rest of catalog swap and link/copy of objects.
> 2) mark all tsvector columns as 83_tsvector and add new tsvector type
> (these columns will be unusable for queries)
> 3) bring up database
> 4) search for all 83_tsvector columns
> 5) do ALTER TABLE on each of these columns, in parallel, up to a
> configuration setting (default 3).

pg_migrator is already emitting a script that is intended to be run
after conversion, to handle REINDEXing of incompatible indexes. That
could easily be made to do ALTER TYPE on old tsvector columns too, no?

The parallel bit is pie in the sky and should not be considered even
for a millisecond during this release cycle. Save it for 8.5, or
suggest to people that they manually cut the script apart if they're
desperate to have that.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2009-05-29 18:46:25 Re: Clean shutdown and warm standby
Previous Message Robert Haas 2009-05-29 18:39:23 Re: explain analyze rows=%.0f