Re: index bloat on partial index 8.4

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Kevin Ricords <kevin(at)silverback(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: index bloat on partial index 8.4
Date: 2011-10-04 19:04:54
Message-ID: CAOR=d=03Lg7qsGLEQMrJdG9sasMdJ76tmGqNi9kdB-Tgis9fZQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Tue, Oct 4, 2011 at 12:28 PM, Kevin Ricords <kevin(at)silverback(dot)com> wrote:
> Thank you for your response.  I believe I misunderstood "reclaimed for
> re-use".  Using contrib/pg_freespace, I see empty index pages can be reused
> elsewhere in the same index, but are not deallocated.  To keep my index at
> the size I expected, I will have to vacuum more frequently or
> reindex/rebuild regularly.

You might need to adjust the various vacuum_* settings to be able to
vacuum aggressively enough to keep with your high update rate. Lower
vacuum_cost_delay and / or autovacuum_vacuum_cost_delay to 1 to 5 ms,
or 0 if you've got an impressive enough IO subsystem. Increate
vacuum_cost_limit to 2 to 10 times what the default is as well. then
keep a close eye on how busy your IO subsystem gets during peak load.
If it goes up too high (stays at 100% for extended periods). then turn
delay back up / cost back down.

As Greg Smith often points out, the solution to autovacuum problems is
usually to make autovacuum more aggressive not less so.

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Robert Burgholzer 2011-10-04 19:18:08 Re: diagnosing a db crash - server exit code 2
Previous Message Kevin Ricords 2011-10-04 18:28:00 Re: index bloat on partial index 8.4