Skip site navigation (1) Skip section navigation (2)

Re: Why will vacuum not end?

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 (view raw or flat)
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

In response to

pgsql-performance by date

Next:From: Manfred KoizarDate: 2004-04-25 00:28:37
Subject: Re: Why will vacuum not end?
Previous:From: Shea,Dan [CIS]Date: 2004-04-24 19:58:08
Subject: Re: Why will vacuum not end?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group