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: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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-29 18:59:39
Message-ID: 200905291859.n4TIxds04742@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> 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?

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(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

In response to

Responses

pgsql-hackers by date

Next:From: Greg StarkDate: 2009-05-29 19:41:38
Subject: Re: search_path vs extensions
Previous:From: Robert HaasDate: 2009-05-29 18:54:02
Subject: Re: Clean shutdown and warm standby

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