Re: Subject: bool / vacuum full bug followup part 2
От | Jeffrey Baker |
---|---|
Тема | Re: Subject: bool / vacuum full bug followup part 2 |
Дата | |
Msg-id | 20020504174847.GA370@noodles обсуждение исходный текст |
Ответ на | Re: Subject: bool / vacuum full bug followup part 2 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Subject: bool / vacuum full bug followup part 2
Re: Subject: bool / vacuum full bug followup part 2 |
Список | 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 по дате отправления: