From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
Subject: | Re: HOT WIP Patch - version 1 |
Date: | 2007-02-14 17:18:42 |
Message-ID: | 26238.1171473522@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(at)enterprisedb(dot)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.
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'".
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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Florian G. Pflug | 2007-02-14 17:22:06 | Re: Writing triggers in C++ |
Previous Message | Magnus Hagander | 2007-02-14 17:06:05 | Re: integer datetimes |