Re: HOT for PostgreSQL 8.3 - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: HOT for PostgreSQL 8.3
Date
Msg-id 1171048361.25938.80.camel@silverbirch.site
Whole thread Raw
In response to Re: HOT for PostgreSQL 8.3  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: HOT for PostgreSQL 8.3  ("Zeugswetter Andreas ADI SD" <ZeugswetterA@spardat.at>)
List pgsql-hackers
On Fri, 2007-02-09 at 13:47 -0500, Tom Lane wrote:
> Hannu Krosing <hannu@skype.net> writes:
> > What are the problems with just shuffling the last (and only visible)
> > tuple to replace the HOT-hain root and be done with it ?
> 
> ctid stops being a reliable identifier.

Yes, that sums it up.

The issue can be overcome in the internals, but the only means of doing
so that seemed workable required changing the output of the CTID special
column. Some applications use the tid datatype directly to relocate rows
within a transaction using the tidscan. ODBC driver uses that concept to
implement Updateable Cursors from the client. We can change that, but
we'd break all the other ones we don't know about. 

This issue was one of the major contributing factors to the size of the
previous HOT prototype, making it more invasive than is really
desirable.

Pointer-swinging avoids those issues and seems workable, even if it is a
pain to have to visit the index during VACUUM. So changing CTID isn't a
bridge we really need to cross, for which I'm glad.

Just as a matter of record, the tuple identifier would need to include
(block, itemid, xmin, cmin) to make this idea work, with the itemid
being that of the root tuple and the xmin and cmin being the tuple in
the chain that is being referenced. This would've then allowed callers
to relocate a specific tuple, even when the update chain had changed
between block accesses. Anyway, glad we're not going there anymore.

--  Simon Riggs              EnterpriseDB   http://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Richard Troy
Date:
Subject: Re: Proposal: Commit timestamp
Next
From: "Andrew Hammond"
Date:
Subject: Re: Proposal: Commit timestamp