| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Greg Stark <stark(at)enterprisedb(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, 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-28 23:32:05 |
| Message-ID: | 20090528233205.GL5156@alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> People who want decent performance on partial match queries (or maybe
> even *any* TS queries) are going to have to convert to the new format
> anyway, though, so maybe this isn't something worth putting a whole lot
> of work into. It might be sufficient if the database conversion
> succeeds but leaves the tsvector columns unusable until they're
> converted.
There are so many caveats on pg_migrator (and things that need to be
done after the migration is complete) that one starts to wonder if
people is not better off just using parallel pg_restore. From Stefan's
reported timings I'm not sure that pg_migrator is that much of a benefit
in the first place ... unless copy mode can be made much faster. (On
link mode it is so much faster that it's worth it, but then you don't
have an escape hatch).
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2009-05-28 23:36:20 | Re: Python 3.0 does not work with PL/Python |
| Previous Message | Kevin Grittner | 2009-05-28 23:32:04 | Re: User-facing aspects of serializable transactions |