Re: large table vacuum issues

From: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
To: "Ed L(dot)" <pgsql(at)bluepolka(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: large table vacuum issues
Date: 2008-01-05 05:29:14
Message-ID: dcc563d10801042129u386044fbwf35ca0aa70744653@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Jan 4, 2008 7:29 PM, Ed L. <pgsql(at)bluepolka(dot)net> wrote:
> On Friday 04 January 2008 6:21 pm, Scott Marlowe wrote:
> >
> > Have you tried adjusting the
> >
> > #vacuum_cost_delay = 0 # 0-1000 milliseconds
> > #vacuum_cost_page_hit = 1 # 0-10000 credits
> > #vacuum_cost_page_miss = 10 # 0-10000 credits
> > #vacuum_cost_page_dirty = 20 # 0-10000 credits
> > #vacuum_cost_limit = 200 # 0-10000 credits
> >
> > settings to something so as to make vacuum less intrusive?
> > might be the easiest fix.
>
> Any particular suggested changes for these parameters?

Well, it really depends on your I/O subsystem, but a good start would
be to read this section of the manual:

http://www.postgresql.org/docs/8.2/interactive/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST

I'd start setting the delay to 10 or 20 and seeing if vacuuming has a
low enough impact to allow it to run in the background, even during
peak hours.

Keep an eye on vmstat / iostat output while vacuum is running to see
if you're flooding your I/O or not.

note that there's a whole other set of vars for autovacuum (at least
in 8.2, don't know about 8.1) that you can set so that regular vacuums
can happen with greater or less priority than autovacuuming.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Joshua D. Drake 2008-01-05 05:39:33 Re: Need efficient way to do comparison with NULL as an option
Previous Message D. Dante Lorenso 2008-01-05 05:23:19 Re: Need efficient way to do comparison with NULL as an option