Re: Restore v. Running COPY/INDEX seperatly

From: Benjamin Arai <me(at)benjaminarai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, "Oleg Bartunov" <oleg(at)sai(dot)msu(dot)su>, "PostgreSQL" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Restore v. Running COPY/INDEX seperatly
Date: 2007-10-15 19:34:36
Message-ID: 48C98F54-E517-4208-80C7-D92856C55190@benjaminarai.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

In what order should I :

- COPY data
- Create indexes
- Create Trigger
- Vaccum

?

Currently I am:

1. Create table
2 . Create trigger for updates
3. Create indexes including gin
4. Vaccum

Benjamin

On Aug 27, 2007, at 7:59 AM, Tom Lane wrote:

> Benjamin Arai <me(at)benjaminarai(dot)com> writes:
>> 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.
>
> Yeah, you'd have the trigger overhead, but the above argument ignores
> the costs of the full-table UPDATE --- not to mention the VACUUM
> you'll need after the UPDATE to clean up the dead rows.
>
> regards, tom lane
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Lee Keel 2007-10-15 20:16:40 Re: Convert bytea to Float8
Previous Message Carlo Stonebanks 2007-10-15 19:23:59 Re: Will UPDATE lock if FROM refers to target table?