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

Re: CREATE INDEX and HOT - revised design

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>,"Florian G(dot) Pflug" <fgp(at)phlo(dot)org>,"Pavan Deolasee" <pavan(dot)deolasee(at)enterprisedb(dot)com>,"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-30 18:35:52
Message-ID: 1175279752.4386.832.camel@silverbirch.site (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, 2007-03-30 at 13:54 -0400, Tom Lane wrote:
> "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> writes:
> > Actually, if we are using Serializable Snapshot then there is no chance
> > to replan the query before the transaction completes and the next
> > transaction to start in the session must see the index and hence
> > we must replan. So it would be enough just to associate a transaction
> > id with the cached plan. If this xid is set and our transaction id is
> > different than that, we replan.
> 
> Hm.  So anytime we reject a potentially useful index as being not valid
> yet, we mark the plan as "only good for this top-level transaction"?
> That seems possibly workable --- in particular it doesn't get more
> complicated as soon as you consider multiple such indexes.

I like that because its specific in dealing with the exact issue we have
- it doesn't rely on many other things happening correctly.

...and it also seems to provide a new route to avoiding the CIC wait.

-- 
  Simon Riggs             
  EnterpriseDB   http://www.enterprisedb.com



In response to

Responses

pgsql-hackers by date

Next:From: Josh BerkusDate: 2007-03-30 18:49:25
Subject: Re: Proposal: include PL/Proxy into core
Previous:From: Florian G. PflugDate: 2007-03-30 18:01:04
Subject: Re: CREATE INDEX and HOT - revised design

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