| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>, "Michael Monnerie" <michael(dot)monnerie(at)is(dot)it-management(dot)at>, pgsql-admin(at)postgresql(dot)org |
| Subject: | Re: Vacuum wait time problem |
| Date: | 2009-02-15 21:02:05 |
| Message-ID: | 26754.1234731725@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> I don't know what other people have found useful, but when I
> experimented with this in our environment, it seemed like I should
> just treat vacuum_cost_delay as a boolean, where 0 meant off and 10
> meant on, and tune it by adjusting vacuum_cost_limit. The granularity
> of vacuum_cost_delay is course and surprising unpredictable.
Making it a boolean is a bit further than I care to go ;-)
What I'd suggest at this point is changing the upper limit to 100ms
(from 1000) and adding documentation suggesting that the value should
be kept small, preferring to use the other vacuum_cost parameters to
tune the behavior.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Haluk Durmus | 2009-02-15 22:34:07 | initdb causes Segmentation fault |
| Previous Message | Kevin Grittner | 2009-02-15 18:50:01 | Re: Vacuum wait time problem |