Re: Restore v. Running COPY/INDEX seperatly - Mailing list pgsql-general

From Alvaro Herrera
Subject Re: Restore v. Running COPY/INDEX seperatly
Date
Msg-id 20070827043027.GA18738@alvh.no-ip.org
Whole thread Raw
In response to Re: Restore v. Running COPY/INDEX seperatly  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Tom Lane wrote:
> Gregory Stark <stark@enterprisedb.com> writes:
> >> On Sun, 26 Aug 2007, Benjamin Arai wrote:
> >>> So, I built my tables which contains a TSearch2 field by
> >>> 1. Create table without indexes
> >>> 2. COPY data into table
> >>> 3. ALTER TABLE tblMessages ADD COLUMN idxFTI tsvector;
> >>> 4. UPDATE tblMessages SET idxFTI=to_tsvector('default', strMessage);
>
> > Or you could set up a trigger to generate the tsvector when you first
> > load the data instead of adding it later.
>
> You're going to want such a trigger anyway, so installing it before the
> COPY step seems like the Obviously Right Thing.  Any other approach
> implies rewriting the entire table after you've loaded it, with no
> compensating advantage that I can see.

Isn't the main speed advantage of the dump the fact that the
to_tsvector() results already come in the COPY data?  The dump already
comes with the idxFTI column contents, instead of having to generate it
from scratch.  That would depend on how expensive that function is, of
course.

--
Alvaro Herrera                 http://www.amazon.com/gp/registry/DXLWNGRJD34J
"PHP is what I call the "Dumb Monkey" language. [A]ny dumb monkey can code
something in PHP. Python takes actual thought to produce something useful."
                                                               (J. Drake)

pgsql-general by date:

Previous
From: Ow Mun Heng
Date:
Subject: Re: Insert or Replace or \copy (bulkload)
Next
From: Ow Mun Heng
Date:
Subject: \copy ignoring Rules Was [Re: Insert or Replace or \copy (bulkload)]