Message-ID: <3C56A0DF.6380290A@tm.ee>
Date: Tue, 29 Jan 2002 15:17:19 +0200
From: Hannu Krosing <hannu@tm.ee>
MIME-Version: 1.0
To: mlw <markw@mohawksoft.com>
CC: Justin Clift <justin@postgresql.org>, 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>
	<3C55B4E7.29F287B2@mohawksoft.com> <3C56506C.2AD21A41@tm.ee>
	<3C569908.2D7254EC@mohawksoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

mlw wrote:
> 
> Hannu Krosing wrote:
> >
> > mlw wrote:
> > >
> > >
> > > Could one run a postgresql process in a lower priority process and
> > > perform lazy vacuums without affecting performance all that much?
> >
> > One must be very careful not to introduce reverse priority problems -
> > i.e. a
> > lower priority process locking some resource and then not letting go
> > while
> > higher priority processes are blocked from running due to needing that
> > lock.
> I understand that, hmm. I wonder if the lock code could boost the priority of a
> process which owns a lock.
> 
> >
> > In my tests 1 vacuum process slowed down 100 concurrent pgbench
> > processes
> > by ~2 times.
> 
> Is that good or bad?

I had hoped it to take somewhat proportional time, i.e. slow other
backends 
down by 1/100.

> > > 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.
> >
> > Isn't this what REINDEX command does ?
> 
> REINDEX can't be run on a live system, can it?

It will probably lock something, but otherways I don't say why it can't.

You may have to add FORCE to the end of command thus:

reindex table tablename force;

-------------
Hannu