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
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 |