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

Re: sequence indexes

From: mlw <markw(at)mohawksoft(dot)com>
To: Justin Clift <justin(at)postgresql(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Zeugswetter Andreas SB SD <ZeugswetterA(at)spardat(dot)at>, Vince Vielhaber <vev(at)michvhf(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: sequence indexes
Date: 2002-01-28 20:30:31
Message-ID: 3C55B4E7.29F287B2@mohawksoft.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Justin Clift wrote:
> 
> Tom Lane wrote:
> >
> > "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)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.

In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2002-01-28 21:18:10
Subject: Per-database and per-user GUC settings
Previous:From: Tom LaneDate: 2002-01-28 20:27:41
Subject: Improving backend launch time by preloading relcache

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