Re: Subject: bool / vacuum full bug followup part 2 - Mailing list pgsql-general

From Jeffrey Baker
Subject Re: Subject: bool / vacuum full bug followup part 2
Date
Msg-id 20020504174847.GA370@noodles
Whole thread Raw
In response to Re: Subject: bool / vacuum full bug followup part 2  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Subject: bool / vacuum full bug followup part 2
Re: Subject: bool / vacuum full bug followup part 2
List pgsql-general
On Fri, May 03, 2002 at 03:47:54PM -0400, Tom Lane wrote:
> Scott Marlowe <scott.marlowe@ihs.com> writes:
> > And reclaimed the space.  Is that the official way, short of dropping and
> > recreating an index to reclaim its space?  Is there a plan to make vacuum
> > reclaim unused space in indexes?
>
> Yes, and yes, but don't hold your breath on the latter part --- that
> TODO item has been around for awhile.  And it's gotten harder now that
> we have lazy VACUUM; that means we need to be able to condense indexes
> concurrently with other index operations.
>
> AFAIK there's not a big problem with index growth if the range of index
> keys remains reasonably static.  The problem comes in if you have a
> range of values that keeps growing (eg, you are indexing a SERIAL or
> timestamp column).  The right end of the btree keeps growing, but
> there's no mechanism to collapse out no-longer-used space at the left
> end.

Wouldn't that explain the complaints I have about my toast tables
always growing?  Because each toast table has an index, and the
above paragraph makes it sound like indexes on serial values grow
all the time, that would imply that table that where tuples live for
windows of time will always be growing.

Or did I read that incorrectly?

-jwb

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Using views and MS access via odbc
Next
From: Masaru Sugawara
Date:
Subject: Re: problem with RULEs