From: | Manfred Koizar <mkoi-pg(at)aon(dot)at> |
---|---|
To: | "Shea,Dan [CIS]" <Dan(dot)Shea(at)ec(dot)gc(dot)ca> |
Cc: | 'Josh Berkus' <josh(at)agliodbs(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Why will vacuum not end? |
Date: | 2004-04-25 00:05:22 |
Message-ID: | h0vl80l9rhr1f5qujnigrh12i7relujqnl@email.aon.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Sat, 24 Apr 2004 15:48:19 -0400, "Shea,Dan [CIS]" <Dan(dot)Shea(at)ec(dot)gc(dot)ca>
wrote:
>Manfred is indicating the reason it is taking so long is due to the number
>of dead tuples in my index and the vacuum_mem setting.
<nitpicking>
Not dead tuples in the index, but dead tuples in the table.
</nitpicking>
>The last delete that I did before starting a vacuum had 219,177,133
>deletions.
Ok, with vacuum_mem = 196608 the bulk delete batch size is ca. 33.5 M
tuple ids. 219 M dead tuples will cause 7 index scans. The time for an
index scan is more or less constant, 60000 seconds in your case. So
yes, a larger vacuum_mem will help, but only if you really have as much
*free* memory. Forcing the machine into swapping would make things
worse.
BTW, VACUUM frees millions of index pages, is your FSM large enough?
Servus
Manfred
From | Date | Subject | |
---|---|---|---|
Next Message | Manfred Koizar | 2004-04-25 00:28:37 | Re: Why will vacuum not end? |
Previous Message | Shea,Dan [CIS] | 2004-04-24 19:58:08 | Re: Why will vacuum not end? |