Re: CREATE INDEX and HOT - revised design

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

In response to

Browse pgsql-hackers by date

  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