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

From Benjamin Arai
Subject Re: Restore v. Running COPY/INDEX seperatly
Date
Msg-id 75C64535-CA65-4982-8972-0740F73E4B25@benjaminarai.com
Whole thread Raw
In response to Re: Restore v. Running COPY/INDEX seperatly  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Restore v. Running COPY/INDEX seperatly  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Why is a trigger faster than doing a ALTER after table is created?  I
thought a trigger would be slower because it would be invoked every
iteration (a new row is inserted) during the COPY process.

Benjamin

On Aug 26, 2007, at 8:43 PM, 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.
>
>             regards, tom lane
>


pgsql-general by date:

Previous
From: Ow Mun Heng
Date:
Subject: \copy ignoring Rules Was [Re: Insert or Replace or \copy (bulkload)]
Next
From: Ow Mun Heng
Date:
Subject: pgloader - Can't find textreader/csvreader