Message-ID: <3C55B4E7.29F287B2@mohawksoft.com>
Date: Mon, 28 Jan 2002 15:30:31 -0500
From: mlw <markw@mohawksoft.com>
MIME-Version: 1.0
To: Justin Clift <justin@postgresql.org>
CC: Tom Lane <tgl@sss.pgh.pa.us>,
	Zeugswetter Andreas SB SD <ZeugswetterA@spardat.at>,
	Vince Vielhaber <vev@michvhf.com>, pgsql-hackers@postgresql.org
Subject: Re: sequence indexes
References: <46C15C39FEB2C44BA555E356FBCD6FA42128E2@m0114.s-mxs.net>
	<6862.1011996346@sss.pgh.pa.us> <3C5263F6.1BADDB0B@postgresql.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Justin Clift wrote:
> 
> Tom Lane wrote:
> >
> > "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> > >> I've looked at the problem a little bit --- there's literature more
> > >> recent than Lehmann-Yao that talks about how to do btree compaction
> > >> without losing concurrency.  But it didn't get done for 7.2.
> >
> > > Yes, there must be. Informix handles this case perfectly.
> > > (It uses a background btree cleaner)
> 
> As an idle thought, I wonder what other maintenance tasks we could have
> a process in the background automatically doing when system activity is
> low ?
> 
> Maintenance
> ***********
> - Index compaction
> - Vacuum of various flavours


I had a couple thoughts about index compaction and vacuum in the
background:

Could one run a postgresql process in a lower priority process and
perform lazy vacuums without affecting performance all that much?

A live index compaction can be done by indexing the table with a
temporary name rename the old index, rename the new index to the old
name, and drop the old index.