Tom Lane wrote:
> Josh Berkus <josh@agliodbs.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?
Hmmm. Well, the problem right now with v8_3_tsvector is that it fails
on index create, even when the index is empty, because I can't figure
out how to simply set up the proper index catalog entries. Once that is
fixed and I can bind tsvector to v8_3_tsvector on schema creation, I can
easily emit ALTER TABLE to fix the issue. And, at that point the
tsvector GIN indexes would be automatically created so I can skip that
part.
> 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.
Agreed.
FYI, this is 1% as hard as the Win32 port, so I am not discouraged. ;-)
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
