From: | "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: HOT is applied |
Date: | 2007-09-21 03:51:53 |
Message-ID: | 2e78013d0709202051o4dd5e29esf854c1e075c06f6a@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 9/21/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>
>
> but control never gets that far because neither xmin nor xmax is
> committed yet. We could fix that, probably, by considering the
> xmin=xmax case in the xmin-in-progress case further up; but the
> HEAP_UPDATED exclusion is still a problem. Still, it seems like this
> is leaving some money on the table when you think about pruning a HOT
> chain. Can we improve on it easily?
>
>
May be we can, but it would get a bit tricky. There might be a transaction
looking at the first tuple in the chain and waiting for this
(inserting-deleting)
transaction to finish. If the waiting transaction is running in READ
COMMITTED
mode, it would then follow the update chain. Removing any intermediate
tuples without fixing the previous tuple's xmax/ctid (or redirected line
pointer)
would be tricky.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Eswar | 2007-09-21 05:42:36 | Query |
Previous Message | Tom Lane | 2007-09-21 03:15:47 | Re: HOT is applied |