From: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Tambet Matiisen <t(dot)matiisen(at)aprote(dot)ee>, josh(at)agliodbs(dot)com, Bill Chandler <billybobc1210(at)yahoo(dot)com>, pgsql-perform <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Question on REINDEX |
Date: | 2005-04-19 18:28:26 |
Message-ID: | 20050419182826.GA18949@dcc.uchile.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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[(at)]dcc(dot)uchile(dot)cl>)
"Crear es tan difícil como ser libre" (Elsa Triolet)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-04-19 18:34:35 | Re: Question on REINDEX |
Previous Message | Tom Lane | 2005-04-19 18:02:34 | Re: Question on REINDEX |