Received: from sss.pgh.pa.us ([192.204.191.242])
	by postgresql.org (8.11.3/8.11.4) with ESMTP id g0PKu5l77917
	for <pgsql-hackers@postgresql.org>;
	Fri, 25 Jan 2002 15:56:05 -0500 (EST)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0PKu5f05380;
	Fri, 25 Jan 2002 15:56:05 -0500 (EST)
To: Vince Vielhaber <vev@michvhf.com>
cc: pgsql-hackers@postgresql.org
Subject: Re: sequence indexes 
In-reply-to: <Pine.BSF.4.40.0201251543310.47994-100000@paprika.michvhf.com> 
References: <Pine.BSF.4.40.0201251543310.47994-100000@paprika.michvhf.com>
Comments: In-reply-to Vince Vielhaber <vev@michvhf.com>
	message dated "Fri, 25 Jan 2002 15:49:33 -0500"
Date: Fri, 25 Jan 2002 15:56:05 -0500
Message-ID: <5377.1011992165@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Archive-Number: 200201/1240
X-Sequence-Number: 18208

Vince Vielhaber <vev@michvhf.com> writes:
> A bit much diskspace for that, isn't it?   The data turns over alot.

Yeah, this is one of the scenarios where we desperately need index
compaction.  The index pages holding the lower serial numbers are
no doubt empty or nearly so, but there's no mechanism for reclaiming
that space short of rebuilding the index.  (BTW you might consider
REINDEX instead of a manual drop/recreate.)

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.

			regards, tom lane