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

Re: How to make lazy VACUUM of one table run in several

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: How to make lazy VACUUM of one table run in several
Date: 2005-04-26 20:23:07
Message-ID: 1114546987.6053.8.camel@fuji.krosing.net (view raw or flat)
Thread:
Lists: pgsql-hackers
On E, 2005-04-25 at 11:11 -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> > On Sun, Apr 24, 2005 at 12:02:37PM +0300, Hannu Krosing wrote:
> >> Must some locks also be released an reaquired inside this loop, or is
> >> there something else I should keep in mind when trying to do this ?
> 
> > There is "session lock" on the table.  You must release that.
> 
> Actually, the only hope of making this work is NOT to release that.
> If you hold the appropriate lock at the session level then it is
> reasonable to consider successive transactions within the vacuum
> as being one big operation.
> 
> I think the major issue with this would be memory management, ie,
> how to prevent CommitTransactionCommand from cleaning up all of
> vacuum's working state.

Are there any known (easy :) tricks for achieving this ?

Now that I have had time to look a little more at this I have another
idea:

Could I avoid having a transaction at all?

As VACUUM is not "transactional" in the sense that it does not change
anything visible to users ever, can't be undone by rollback, etc... ,
could it be possible to create enough "transaction-like" environment for
it to really run outside of transactions. Perhaps just advancing
oldestXmin at certain intervals ?

-- 
Hannu Krosing <hannu(at)tm(dot)ee>

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2005-04-26 20:31:38
Subject: Re: [HACKERS] Bad n_distinct estimation; hacks suggested?
Previous:From: David WheelerDate: 2005-04-26 20:19:42
Subject: Re: DO INSTEAD and conditional rules

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