Message-ID: <3C569908.2D7254EC@mohawksoft.com>
Date: Tue, 29 Jan 2002 07:43:52 -0500
From: mlw <markw@mohawksoft.com>
MIME-Version: 1.0
To: Hannu Krosing <hannu@tm.ee>
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>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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?

> 
> > 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?


> 
> ---------------
> Hannu