| From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
|---|---|
| To: | "D'Arcy J(dot)M(dot) Cain" <darcy(at)druid(dot)net> |
| Cc: | pgsql-hackers(at)PostgreSQL(dot)org |
| Subject: | Re: Possible documentation error |
| Date: | 2006-12-26 17:12:45 |
| Message-ID: | 20061226171245.GD8412@svana.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Dec 26, 2006 at 12:04:40PM -0500, D'Arcy J.M. Cain wrote:
> I have been testing this statement and find that it seems not quite
> true. Although ctid changes on update, VACUUM FULL does not change it.
> What it does do is make lower areas available again so an update after a
> VACUUM FULL can reuse lower numbers rather than higher ones before.
A VACUUM FULL will try to compact a table. Thus if there's a lot of
free space at the beginning, it will move tuples near the end to the
beginning.
> Now it certainly seems to me that it should behave as described given
> the definition of VACUUM FULL so I am a little confused by my tests.
> My test table only has two entries in it. Is that the issue? In fact,
> I find the same behaviour if I do a simple VACUUM on the table.
On a table with two entries, VACUUM FULL is going to do nothing of
interest. Moving tuples within a page is useless, generally.
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Fuhr | 2006-12-26 17:23:52 | Re: Possible documentation error |
| Previous Message | D'Arcy J.M. Cain | 2006-12-26 17:04:40 | Possible documentation error |