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

Re: CREATE INDEX and HOT - revised design

From: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
To: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 10:14:44
Message-ID: 460B9194.9090608@phlo.org (view raw or flat)
Thread:
Lists: pgsql-hackers
Pavan Deolasee wrote:
> In this specific context, this particular case is easy to handle because
> we are only concerned about the serializable transactions started before
> CREATE INDEX commits. If PREPARE can see the new index, it
> implies that the CI transaction is committed. So the transaction
> starting after than can only see the tuple version that we have indexed.

Yes, but the non-index plan PREPARE generated will be used until the end
of the session, nut only until the end of the transaction. Imagine that
it wasn't explicitly PREPARED (where you might say this is acceptable),
but rather just a query inside a plpgsql function, maybe even called
from some app using connection pooling. This means that the non-index
using plan might get used for a quite long time, which contradics the
work Tom did on plan invalidation I think.

Maybe Tom can comment on wheter it's possible to use plan invalidation
to eventually get rid of a stale plan in this context?

greetings, Florian Pflug


In response to

Responses

pgsql-hackers by date

Next:From: Pavan DeolaseeDate: 2007-03-29 10:41:50
Subject: Re: CREATE INDEX and HOT - revised design
Previous:From: Simon RiggsDate: 2007-03-29 10:07:12
Subject: Re: [PATCHES] Full page writes improvement, code update

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