| 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: | Whole Thread | Raw Message | 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 |