| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | Ron St-Pierre <ron(dot)pgsql(at)shaw(dot)ca> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: 12 hour table vacuums |
| Date: | 2007-10-23 16:12:04 |
| Message-ID: | 20071023161204.GK18013@alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Ron St-Pierre wrote:
> Okay, here's our system:
> postgres 8.1.4
Upgrade to 8.1.10
> Here's the table information:
> The table has 140,000 rows, 130 columns (mostly NUMERIC), 60 indexes.
60 indexes? You gotta be kidding. You really have 60 columns on which
to scan?
> vacuum_cost_delay = 200
> vacuum_cost_limit = 100
Isn't this a bit high? What happens if you cut the delay to, say, 10?
(considering you've lowered the limit to half the default)
--
Alvaro Herrera Developer, http://www.PostgreSQL.org/
"Someone said that it is at least an order of magnitude more work to do
production software than a prototype. I think he is wrong by at least
an order of magnitude." (Brian Kernighan)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Csaba Nagy | 2007-10-23 16:21:16 | Re: 12 hour table vacuums |
| Previous Message | Tom Lane | 2007-10-23 16:11:51 | Re: 12 hour table vacuums |