| From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
|---|---|
| To: | Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> |
| Cc: | raghavendra t <raagavendra(dot)rao(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: How to fast the REINDEX |
| Date: | 2010-04-01 03:11:36 |
| Message-ID: | 4BB40EE8.2080005@postnewspapers.com.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Jaime Casanova wrote:
> On Wed, Mar 31, 2010 at 5:33 PM, raghavendra t
> <raagavendra(dot)rao(at)gmail(dot)com> wrote:
>>>> Why are you doing that?
>> Our table face lot of updates and deletes in a day, so we prefer reindex to
>> update the indexes as well overcome with a corrupted index.
>>
>
> do you have a corrupted index? if not, there is nothing to do...
> REINDEX is not a mantenance task on postgres
Actually, if your free_space_map (pre 8.4) isn't up to keeping track of
bloat, or autovac isn't running enough, you're likely to get bloat of
indexes as well as tables that may need VACUUM FULL + REINDEX to
properly clean up.
It's probably better to fix your fsm/autovac settings then CLUSTER the
table so it doesn't happen again, though.
--
Craig Ringer
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2010-04-01 10:54:33 | Re: How to fast the REINDEX |
| Previous Message | Bruce Momjian | 2010-04-01 00:44:25 | Re: temp table "on commit delete rows": transaction overhead |