From: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com> |
---|---|
To: | Greg Smith <gsmith(at)gregsmith(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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:45:48 |
Message-ID: | 1253213148.778.300.camel@hvost1700 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2009-09-17 at 14:33 -0400, Greg Smith wrote:
> 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.
I understood that the main difficulty for in-place tuple expansion was
keeping CTIDs to not need to update indexes.
Current tuple mover discussion does not address that.
But maybe something can be tahen from this discussion the other way
round - maybe we should not be afraid of doing null updates during
in-place update
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Consulting and Training
From | Date | Subject | |
---|---|---|---|
Next Message | Dan Colish | 2009-09-17 18:50:28 | Re: generic copy options |
Previous Message | Greg Smith | 2009-09-17 18:33:05 | Re: Feedback on getting rid of VACUUM FULL |