Re: Visibility map thoughts
От | Marko Kreen |
---|---|
Тема | Re: Visibility map thoughts |
Дата | |
Msg-id | e51f66da0711060540w3777cf22o885dd69d9d84b521@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Visibility map thoughts (Heikki Linnakangas <heikki@enterprisedb.com>) |
Список | pgsql-hackers |
On 11/6/07, Heikki Linnakangas <heikki@enterprisedb.com> wrote: > Marko Kreen wrote: > > On 11/6/07, Heikki Linnakangas <heikki@enterprisedb.com> wrote: > >> (Gosh, we really need a name for the sort of vacuum. I was about to say > >> "we'd still need regular regular VACUUMs" :-)) > > > > As the new VACUUM variant will be somewhat unsafe, it should > > not replace "regular" VACUUM but get separate name. > > What do you mean by unsafe? It is supposed to reclaim all dead tuples a > normal vacuum would, except for HOT updated tuples that can be pruned > without scanning indexes. It doesn't advance the relfrozenxid or update > stats, though. I got the impression from this paragraph: "This kind of map is useful for VACUUM as well, though VACUUM could get away with less strict semantics, and we might not want to visit a page in VACUUM if there's only very few dead tuples on a page." That seems to hint that the current VACUUM needs still be run occasionally. > > VACUUM FAST maybe? Informally "fastvacuum". Something with > > "lazy" or "partial" would also be possibility. > > We already call the regular vacuum "lazy" in the source code, as opposed > to VACUUM FULL. Partial is also bit misleading; while it doesn't scan > the whole table, it should find all dead tuples. As the VACUUM FULL is unusable in real life, maybe we should move current VACUUM functionality under VACUUM FULL ;) -- marko
В списке pgsql-hackers по дате отправления: