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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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