Re: GLOBAL vs LOCAL temp tables

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: GLOBAL vs LOCAL temp tables
Дата
Msg-id 29801.1050521974@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: GLOBAL vs LOCAL temp tables  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: GLOBAL vs LOCAL temp tables
Список pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I am asking more from a theoretical perspective --- can we say VACUUM
> regularly or VACUUM FULL are the same in terms of index recovery, or at
> least as similar as FULL/non-FULL are?

See the comments in nbtree.c's btvacuumcleanup().  FULL is able to
recycle empty pages faster than non-FULL, since it knows there can be no
other transactions with open indexscans.  So a freshly emptied index
page can be added to the FSM freelist immediately, whereas in the
non-FULL case it will need to wait till the next VACUUM (possibly even
longer if you have long-running transactions).  Also, VACUUM FULL will
truncate off any free pages at the end of the index, though I doubt this
is very effective since it won't move data across pages.

As I commented to Alvaro, I don't really see a need for an intermediate
level of cleanup between what VACUUM FULL does now and REINDEX.  Moving
data in an index is slow, would certainly require exclusive lock, and
helps to degrade the physical ordering of the index.  REINDEX gives you
a nice new freshly-sorted index and would probably be what you'd want
if you were going to lock down the index for a long period anyway.

> I don't remember the btree index
> compaction fix in CVS --- I just remember the recording of index free
> space by VACUUM --- did I forget something?

It's in there.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: mlw
Дата:
Сообщение: Re: Foreign Database Connectivity
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Transaction problem?