Re: HOT for PostgreSQL 8.3

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Hannu Krosing" <hannu(at)skype(dot)net>, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, <pgsql-hackers(at)postgresql(dot)org>, "Pavan Deolasee" <pavan(dot)deolasee(at)enterprisedb(dot)com>, "Nikhil S" <nikhil(dot)sontakke(at)enterprisedb(dot)com>
Subject: Re: HOT for PostgreSQL 8.3
Date: 2007-02-09 19:12:40
Message-ID: 1171048361.25938.80.camel@silverbirch.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 2007-02-09 at 13:47 -0500, Tom Lane wrote:
> Hannu Krosing <hannu(at)skype(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Hammond 2007-02-09 19:19:41 Re: Proposal: Commit timestamp
Previous Message Tom Lane 2007-02-09 18:47:40 Re: HOT for PostgreSQL 8.3