From: | Jeffrey Baker <jwbaker(at)acm(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Scott Marlowe <scott(dot)marlowe(at)ihs(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Subject: bool / vacuum full bug followup part 2 |
Date: | 2002-05-04 17:48:47 |
Message-ID: | 20020504174847.GA370@noodles |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, May 03, 2002 at 03:47:54PM -0400, Tom Lane wrote:
> Scott Marlowe <scott(dot)marlowe(at)ihs(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alan Wayne | 2002-05-04 19:09:49 | Re: HOWTO - Random character generation for primary key |
Previous Message | Masaru Sugawara | 2002-05-04 17:41:34 | Re: problem with RULEs |