Skip site navigation (1) Skip section navigation (2)

Rebuild indexes

From: Shankar K <shan0075(at)yahoo(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Rebuild indexes
Date: 2003-07-28 21:29:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-adminpgsql-performance
Hi Everyone,

I've a kind of less inserts/mostly updates table,
which we vacuum every half-hour. 

here is the output of vacuum analyze 

INFO:  --Relation public.accounts--
INFO:  Index accounts_u1: Pages 1498; Tuples 515:
Deleted 179.
	CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  Index accounts_u2: Pages 2227; Tuples 515:
Deleted 179.
	CPU 0.00s/0.00u sec elapsed 0.01 sec.
INFO:  Index accounts_u3: Pages 246; Tuples 515:
Deleted 179.
	CPU 0.00s/0.00u sec elapsed 0.00 sec.

however its indexes keeps growing on and on. After
surfing the manuals for a while, i came to know that
vacuum doesn't clears up dead tuples caused by
updates. so i then decided to do reindex online, but
that makes exclusive lock on table which would prevent

writing on to tables.

finally i'm at a point where i decided to do index

for e.g.

1. create index accounts_u1_swap,accounts_u2_swap and
accounts_u3_swap in addition to the original indexes

2. analyze table to update stats, so that the table
knows about new indexes.

3. drop original indexes

4. i wish i had a rename index command to rename _swap
to its original index name. now create indexes with
original name

5. follow #2  and #3 (now drop _swap indexes)

Is there a better way to do this. comments are


Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software


pgsql-performance by date

Next:From: Josh BerkusDate: 2003-07-29 00:18:59
Subject: Re: [PERFORM] Rebuild indexes
Previous:From: Josh BerkusDate: 2003-07-28 19:27:44
Subject: Re: Optimization

pgsql-admin by date

Next:From: scott.marloweDate: 2003-07-28 21:31:41
Subject: Re: Performance tunning
Previous:From: Romildo WildgrubeDate: 2003-07-28 21:23:03
Subject: Performance tunning

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group