Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: NikhilSDate: 2007-03-31 05:14:53
Subject: Re: UPDATE using sub selects
Previous:From: Pavan DeolaseeDate: 2007-03-31 03:45:22
Subject: Re: CREATE INDEX and HOT - revised design

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group