Re: Question on REINDEX

От: Alvaro Herrera
Тема: Re: Question on REINDEX
Дата: ,
Msg-id: 20050419182826.GA18949@dcc.uchile.cl
(см: обсуждение, исходный текст)
Ответ на: Re: Question on REINDEX  (Tom Lane)
Ответы: Re: Question on REINDEX  (Tom Lane)
Список: pgsql-performance

Скрыть дерево обсуждения

Question on REINDEX  (Bill Chandler, )
 Re: Question on REINDEX  (Josh Berkus, )
  Re: Question on REINDEX  (Tom Lane, )
 Re: Question on REINDEX  (Bruno Wolff III, )
 Re: Question on REINDEX  ("Tambet Matiisen", )
  Re: Question on REINDEX  (Tom Lane, )
   Re: Question on REINDEX  (Alvaro Herrera, )
    Re: Question on REINDEX  (Tom Lane, )
  Re: Question on REINDEX  (Josh Berkus, )
   Re: Question on REINDEX  (Tom Lane, )
    Re: Question on REINDEX  (Josh Berkus, )
     Re: Question on REINDEX  (Tom Lane, )

On Tue, Apr 19, 2005 at 10:06:40AM -0400, Tom Lane wrote:

> BTW, VACUUM FULL does the data movement back-to-front, and stops as soon
> as it finds a tuple it cannot move down; which is a reasonable strategy
> since the goal is merely to make the file shorter.  But it's entirely
> likely that there will be lots of empty space left at the end.  For
> instance the final state could have one 4K tuple in the last page and
> up to 4K-1 free bytes in every earlier page.

Am I right in thinking that vacuum does at least two passes: one
front-to-back to find removable tuples, and other back-to-front for
movement?  Because if it doesn't work this way, it wouldn't relabel
(change Xmin/Xmax) tuples in early pages.  Or does it do something
different?

I know maintenance_work_mem is used for storing TIDs of to-be-moved
tuples for index cleanup ... how does it relate to the above?

--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"Crear es tan difícil como ser libre" (Elsa Triolet)


В списке pgsql-performance по дате сообщения:

От: "Jim C. Nasby"
Дата:
Сообщение: Re: How to improve db performance with $7K?
От: "Jim C. Nasby"
Дата:
Сообщение: Re: immutable functions vs. join for lookups ?