[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [HACKERS] Possible documentation error
From:       Bruce Momjian <bruce () momjian ! us>
Date:       2006-12-30 20:30:27
Message-ID: 200612302030.kBUKURd08390 () momjian ! us
[Download RAW message or body]

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                                            jim@nasby.net
> 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   bruce@momjian.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

["/bjm/diff" (/bjm/diff)]

? 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


[prev in list] [next in list] [prev in thread] [next in thread]