Tom Lane wrote: > Josh Berkus <j...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
