Re: Subject: bool / vacuum full bug followup part 2
От | Bruce Momjian |
---|---|
Тема | Re: Subject: bool / vacuum full bug followup part 2 |
Дата | |
Msg-id | 200206030256.g532ur604192@candle.pha.pa.us обсуждение исходный текст |
Ответ на | 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
|
Список | pgsql-general |
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. Can you remind me why it is so hard to fix this. I do not expect lazy vacuum to handle index shrinking, but it should be possible with full vacuum. > 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. I must say I am embarrased by our failure to shrink all indexes. I haven't said this before because no one has complained. I am sure lots of people are affected by this, but few realize it because few analyze did space. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
В списке pgsql-general по дате отправления: