| From: | "Phoenix Kiula" <phoenix(dot)kiula(at)gmail(dot)com> |
|---|---|
| To: | "Vivek Khera" <vivek(at)khera(dot)org> |
| Cc: | "Postgres General" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: For index bloat: VACUUM ANALYZE vs REINDEX/CLUSTER |
| Date: | 2007-09-25 01:18:15 |
| Message-ID: | e373d31e0709241818k17c82e3boc2666fbc5e05236c@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 25/09/2007, Vivek Khera <vivek(at)khera(dot)org> wrote:
> Recommending I run vacuum intermixed with the data purge is a non-
> starter; the vacuum on these tables takes a couple of hours. I'd
> never finish purging my data with that kind of delay.
...
> I will investigate the fill-factor. That seems like it may make some
> sense the way I do inserts and updates...
Undoubtedly.
But if most of your indexed keys are gone, then a reindex is useful.
If this is a hugely live system and you don't have a great number of
indexes, then a somewhat kludgish way to try could be to create a copy
of the table, do what you wish with it (delete rows, index them, then
cluster them on that index)...and whenever the process finishes (3
hours, or 3 days...no matter, because it doesn't hurt your live
system), you simply rename the old table to TABLE_OLD and the new
table to TABLE. The renaming operation is instant.
Anyway, what is your maintenance_work_mem? Try increasing your
maintenance_work_mem and see if that helps vacuuming first. Vacuum
operations can be sped up dramatically. We need regular vacuums and
that is critical to our application, so I have a m_w_m of 512K.
Mind you -- even if your DB vacuums for a couple hours, vacuum doesn't
affect the performance of your live system while it is happening, so
frequent vacuuming cannot hurt you one way or another, and it can
surely help.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tatsuo Ishii | 2007-09-25 01:21:53 | Re: about pgpool question |
| Previous Message | Gregory Stark | 2007-09-25 01:10:37 | Re: table column reordering |