From: | "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Pavan Deolasee" <pavan(dot)deolasee(at)enterprisedb(dot)com>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, "Bruce Momjian" <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: CREATE INDEX and HOT - revised design |
Date: | 2007-03-31 04:03:55 |
Message-ID: | 2e78013d0703302103l7c1b4095o3d007fcf87de6b23@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3/30/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>
> I do not think you can assume that the plan won't be used later with
> some older snapshot. Consider recursive plpgsql functions for a
> counterexample: the inner occurrence might be the first to arrive at
> a given line of the function, hence the first to plan it, yet when we
> return to the outer instance we might revert to an older snapshot.
Thanks for making me aware of such scenarios. What it also means
is that a transaction may use an older snapshot after it created the
index. So to be on safer side, we should not use an index created
in the same transaction if we saw HOT-updated RECENTLY_DEAD
or DELETE_IN_PROGRESS tuples while building the index (with HOT
we don't want to index these tuples). Not such a bad restriction to
live with. May be we can do something with command ids to solve
this once we get the basic stuff ready.
Thanks,
Pavan
--
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | NikhilS | 2007-03-31 05:14:53 | Re: UPDATE using sub selects |
Previous Message | Pavan Deolasee | 2007-03-31 03:45:22 | Re: CREATE INDEX and HOT - revised design |