OK, wording updated. Thanks. ---------------------------------------------------------------------------
Jim C. Nasby wrote: > On Tue, Dec 26, 2006 at 07:22:21PM +0100, Martijn van Oosterhout wrote: > > On Tue, Dec 26, 2006 at 12:49:55PM -0500, D'Arcy J.M. Cain wrote: > > > On Tue, 26 Dec 2006 18:12:45 +0100 > > > Martijn van Oosterhout <kleptog@svana.org> wrote: > > > > On Tue, Dec 26, 2006 at 12:04:40PM -0500, D'Arcy J.M. Cain wrote: > > > > > 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. > > > > > > I thought that that might be the issue. The docs should probably say > > > "can" instead of "will" then. > > > > The doumenttion is accurate as is. It says when "moved by VACUUM FULL". > > In your case they wern't moved. If you change the word "will" to "can", > > it will be wrong. > > Howso? There's no guarantee (which is what "will" implies) that a ctid > will change on VACUUM FULL. In fact, your example demonstrates that; 0,1 > stayed put. > > I'm sorry if it sounds like I'm picking nits, but using CTID to > identify rows could provide a noticeable performance gain in some cases. > But users can't make use of that if it's not clear exactly when and how > CTIDs can change. > -- > Jim Nasby [EMAIL PROTECTED] > EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
? HISTORY.html Index: ddl.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/ddl.sgml,v retrieving revision 1.69 diff -c -r1.69 ddl.sgml *** ddl.sgml 28 Nov 2006 01:09:01 -0000 1.69 --- ddl.sgml 30 Dec 2006 20:24:19 -0000 *************** *** 974,980 **** The physical location of the row version within its table. Note that although the <structfield>ctid</structfield> can be used to locate the row version very quickly, a row's ! <structfield>ctid</structfield> will change each time it is updated or moved by <command>VACUUM FULL</>. Therefore <structfield>ctid</structfield> is useless as a long-term row identifier. The OID, or even better a user-defined serial --- 974,980 ---- The physical location of the row version within its table. Note that although the <structfield>ctid</structfield> can be used to locate the row version very quickly, a row's ! <structfield>ctid</structfield> will change if it is updated or moved by <command>VACUUM FULL</>. Therefore <structfield>ctid</structfield> is useless as a long-term row identifier. The OID, or even better a user-defined serial
---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster