Re: Thoughts on maintaining 7.3
От | Bruce Momjian |
---|---|
Тема | Re: Thoughts on maintaining 7.3 |
Дата | |
Msg-id | 200310091936.h99JaCu29438@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Thoughts on maintaining 7.3 (Alvaro Herrera <alvherre@dcc.uchile.cl>) |
Список | pgsql-hackers |
Added to TODO: * Have VACUUM FULL use REINDEX rather than index vacuum --------------------------------------------------------------------------- Alvaro Herrera wrote: > On Sat, Oct 04, 2003 at 11:53:49PM -0400, Tom Lane wrote: > > Alvaro Herrera <alvherre@dcc.uchile.cl> writes: > > > > Imagine having to VACUUM FULL a huge > > > table. Not only it will take the lot required to do the VACUUM in the > > > heap itself, it will also have to rebuild all indexes from scratch. > > > > A very large chunk of VACUUM FULL's runtime is spent fooling with the > > indexes. Have you looked at the code in any detail? It goes like this: > > Hmm. No, I haven't looked at that code too much. You are probably > right, of course. Maybe the indexes could be dropped altogether and > then recreated after the vacuum is over, similar to what the cluster > code does. This would be similar to REINDEX, I suppose. (I haven't > actually looked at the REINDEX code either.) > > > > > I think there are scenarios where the REINDEX will be much worse, say when > > > there are not too many deleted tuples (but in that case, why is the user > > > doing VACUUM FULL in the first place?). > > > > Yeah, I think that's exactly the important point. These days there's > > not a lot of reason to do VACUUM FULL unless you have a major amount of > > restructuring to do. I would once have favored maintaining two code > > paths with two strategies, but now I doubt it's worth the trouble. > > (Or I should say, we have two code paths, the other being lazy VACUUM > > --- do we need three?) > > There are two points that could be made here: > > 1. We do not want users having to think too hard about what kind of > VACUUM they want. This probably botches Bruce's idea of an additional > VACUUM DATA command. > > 2. We do not want to expose the VACUUM command family at all. The > decisions about what code paths should be taken are best left to the > backend-integrated vacuum daemon, which has probably much better > information than users. > > -- > Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) > "You knock on that door or the sun will be shining on places inside you > that the sun doesn't usually shine" (en Death: "The High Cost of Living") > -- 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 по дате отправления: