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: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pavan Deolasee <pavan(dot)deolasee(at)enterprisedb(dot)com>, 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>
Subject: Re: CREATE INDEX and HOT - revised design
Date: 2007-03-30 16:54:14
Message-ID: 460D40B6.6000208@phlo.org (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> "Pavan Deolasee" <pavan(dot)deolasee(at)enterprisedb(dot)com> writes:
>> What I am suggesting is to use ActiveSnapshot (actually
>> Florian's idea) to decide whether the transaction that created
>> index was still running when we started. Isn't it the case that
>> some snapshot will be "active" when we plan ?
> 
> 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.

So maybe we'd need to use the SerializableSnapshot created at the start
of each transaction for this check, and not the ActiveSnapshot? Could
that work?

What about doing
PREPARE myplan select ... ;
outside of a transaction? Will this be execute inside a transaction?
Is is a query always planned upon it's first execution, and not when
"PREPARE" is issued?

greetings, Florian Pflug



In response to

Responses

pgsql-hackers by date

Next:From: Pavan DeolaseeDate: 2007-03-30 16:59:26
Subject: Re: CREATE INDEX and HOT - revised design
Previous:From: Tom LaneDate: 2007-03-30 16:52:12
Subject: Re: CREATE INDEX and HOT - revised design

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