From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David Monarchi" <david(dot)e(dot)monarchi(at)gmail(dot)com> |
Cc: | pgsql-novice(at)postgresql(dot)org |
Subject: | Re: unreasonable run time for vacuum analyze? |
Date: | 2007-06-13 01:14:11 |
Message-ID: | 29056.1181697251@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
"David Monarchi" <david(dot)e(dot)monarchi(at)gmail(dot)com> writes:
> One table in the database contains 22.6M rows of 71 fields with an average
> length of about 500 bytes. The table is in BCNF. The table is queried in a
> wide variety of ways. There are 37 btree and Gin indexes defined on the
> table. The GIN indexes are on array fields. The rest are btree.
37 indexes? Yoi. You should think harder about whether every one of
them really pulls its weight, because VACUUM is when they cost you.
> I started running vacuum analyze on this table over 44 hours ago, and it is
> still running. The load on the machine has been modest. There have been no
> times when all eight processors were being used.
I/O bound no doubt; have you been watching I/O status? Or, if you have
vacuum_cost_delay enabled, maybe it's set too high.
> 3) are there parameters that I can set to improve the performance of the
> vacuum analyze process?
What is maintenance_work_mem set to?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Lefevre | 2007-06-13 02:43:42 | inputs for pg_get_id() function? |
Previous Message | Tom Lane | 2007-06-13 00:51:09 | Re: Joins within a table |