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

Re: CREATE INDEX and HOT - revised design

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
Cc: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Pavan Deolasee <pavan(dot)deolasee(at)enterprisedb(dot)com>
Subject: Re: CREATE INDEX and HOT - revised design
Date: 2007-03-29 15:45:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Florian G. Pflug" <fgp(at)phlo(dot)org> writes:
> Pavan Deolasee wrote:
>> Frankly I don't know this works, but are you sure that the plan will
>> be used until the end of the session ? Even if thats the case, it can
>> happen even today if we create a new index, but the existing sessions
>> will use the stale plan (assuming what you said is true)

> I've checked that:

Evidently you weren't testing on HEAD.

> The open question is how CVS HEAD with plan invalidation behaves.
> If it replans after the index-creating transaction commits, then
> basing index validity on a snapshot will break this, because upon
> replay they index might not be useable, but later on it may very
> well be (but that plan invalidation machinery won't realize that)

It will replan at the first use of the plan after seeing the relcache
inval sent by commit of the index-creating transaction.  If you have
two separate transactions to create an index and then mark it valid
later, everything's fine because there are two inval events.
However, if you design something where an index becomes usable due
to the passage of time rather than an explicit mark-valid step,
there's gonna be a problem.  I'd suggest trying to stick to the

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2007-03-29 16:05:49
Subject: Re: Modifying TOAST thresholds
Previous:From: Magnus HaganderDate: 2007-03-29 15:33:45
Subject: Re: ECPG regression tests expected files

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