| From: | Greg Smith <gsmith(at)gregsmith(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Feedback on getting rid of VACUUM FULL |
| Date: | 2009-09-17 18:33:05 |
| Message-ID: | alpine.GSO.2.01.0909171429420.19480@westnet.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 16 Sep 2009, Tom Lane wrote:
>> * Shrink a table in place - when no space available
> To be addressed by the UPDATE-style tuple-mover (which could be thought
> of as VACUUM FULL rewritten to not use any special mechanisms).
Is there any synergy here with the needs of a future in-place upgrade
upgrade mechanism that handles page header expansion? That problem seemed
to always get stuck on the issue of how to move tuples around when the
pages were full. Not trying to drag the scope of this job out, just
looking for common ground that might be considered when designing the
tuple-mover if it could serve both purposes.
--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2009-09-17 18:45:48 | Re: Feedback on getting rid of VACUUM FULL |
| Previous Message | Bruce Momjian | 2009-09-17 18:31:51 | Re: Schedule for 8.5 Development |