Re: REINDEX during a transaction

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

In response to

Browse pgsql-admin by date

  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