Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
