Re: HOT WIP Patch - version 1

Tom Lane wrote:
> Heikki Linnakangas <heikki@enterprisedb.com> writes:
>> What's the verdict on relaxing the "live tuple's ctid doesn't change 
>> rule"?
> 
> I think that's unacceptable; it is known that that will break the ODBC
> and JDBC drivers, as well as any other programs that make use of the
> ctid for re-finding a tuple they read earlier in the same transaction.

AFAIK the JDBC driver doesn't use ctid. But ODBC and other programs do.

> We have not only never deprecated client-side use of ctid for this, but
> actively encouraged it, for instance by going out of our way to support
> fast access for queries "WHERE ctid = 'constant'".

The idea I had was to change what the ctid system column returns to 
root ctid + xmin + cmin. As long as programs treat the ctid as an opaque 
string, it should work. Tid scan would use that to locate the original 
tuple.

> What's more, your proposal would break plain old UPDATE and DELETE,
> as well as SELECT FOR UPDATE, none of which promise to hold a pin
> continuously on every page containing a tuple they might decide to
> revisit (by ctid) later.  Are you prepared to disallow hash join and
> sort/merge join in all such queries?

No, of course not. We'd have to do the same thing here; use root tid + 
xmin + cmin instead of just ctid.

But now that I think of it, how do we get the root tid of a tuple? I 
suppose we'd be back to having backpointers or scanning the whole 
page... I guess pointer-swinging it is, then.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com