From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Ashley Moran <ashley(dot)moran(at)codeweavers(dot)net>, pgsql-admin(at)postgresql(dot)org |
Subject: | Re: REINDEX during a transaction |
Date: | 2006-03-01 19:21:33 |
Message-ID: | 20060301192133.GL82012@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Wed, Mar 01, 2006 at 10:23:41AM -0500, Tom Lane wrote:
> Ashley Moran <ashley(dot)moran(at)codeweavers(dot)net> writes:
> > BEGIN WORK;
> > DELETE FROM X; COPY X ...; REINDEX TABLE X;
> > DELETE FROM Y; COPY Y ...; REINDEX TABLE Y;
> > DELETE FROM Z; COPY Z ...; REINDEX TABLE Z;
> > COMMIT;
>
> Why don't you use TRUNCATE? Why do you think you need REINDEX at all?
>
> If you do need it, you'd be best off to drop the indexes, truncate,
> copy, re-create the indexes. See
> http://www.postgresql.org/docs/8.1/static/populate.html#POPULATE-RM-INDEXES
And to answer some of your original question, I don't believe there's
any advantage to wrapping the REINDEXes into the transaction. If can't
use Tom's suggestion of dropping the indexes before the COPY, you might
want to instead create new indexes with the same definition of existing
ones, and then drop the old ones; readers of the table will react
differently to the two.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2006-03-01 19:25:32 | Re: PostgreSQL performance tuning |
Previous Message | Jason Minion | 2006-03-01 17:23:22 | Re: problem in sequence |