Re: Thoughts on maintaining 7.3
От | Bruce Momjian |
---|---|
Тема | Re: Thoughts on maintaining 7.3 |
Дата | |
Msg-id | 200310091930.h99JUIQ28683@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Thoughts on maintaining 7.3 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Thoughts on maintaining 7.3
|
Список | pgsql-hackers |
Tom Lane wrote: > Alvaro Herrera <alvherre@dcc.uchile.cl> writes: > > I think what Tom is concerned about is that this hasn't been tested > > enough with big datasets. Also there a little loss of index pages but > > it's much less (orders of magnitude, I think) than what was before. > > This is because the index won't shrink "vertically". > > The fact that we won't remove levels shouldn't be meaningful at all --- > I mean, if the index was once big enough to require a dozen btree > levels, and you delete everything, are you going to be upset that it > drops to 13 pages rather than 2? I doubt it. > > The reason I'm waffling about whether the problem is completely fixed or > not is that the existing code will only remove-and-recycle completely > empty btree pages. As long as you have one key left on a page it will > stay there. So you could end up with ridiculously low percentage-filled > situations. This could be fixed by collapsing together adjacent > more-than-half-empty pages, but we ran into a lot of problems trying to > do that in a concurrent fashion. So I'm waiting to find out if real > usage patterns have a significant issue with this or not. If we have an exclusive lock during VACUUM FULL, should we just collapse the pages rather than REINDEX? I realize we might have lots of expired index tuples because VACUUM FULL creates new ones as part of reorganizing the heap. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: