| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Greg Stark <gsstark(at)mit(dot)edu> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: remove flatfiles.c |
| Date: | 2009-09-02 19:49:46 |
| Message-ID: | 26362.1251920986@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> It scans pages *backwards* from the end (which does wonderful things
> on rotating media). Marks each live tuple it finds as "moved off",
> finds a new place for it (using the free space map I think?).
BTW, VACUUM FULL doesn't use the free space map --- that code predates
the FSM by a lot. It builds its own map of free space during its
initial lazy-VACUUM-equivalent scan that just removes dead tuples.
While I don't think this hurts performance any, I have seen reports of
VACUUM FULL failing outright on large tables because it runs out of
memory for this map. So that's still another way in which it's not
actually all that useful for huge tables.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Selena Deckelmann | 2009-09-02 19:50:18 | Re: community decision-making & 8.5 |
| Previous Message | Tom Lane | 2009-09-02 19:45:49 | Re: remove flatfiles.c |