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

Re: CREATE INDEX and HOT - revised design

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>, 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 17:55:16
Message-ID: 200703291755.l2THtG414263@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Pavan Deolasee wrote:
> > Earlier we were talking about not inserting any HOT tuples until the index
> > became valid. The goal of having an xid on the index was so we would know
> > when
> > we could start doing HOT updates again. That seems like a much lesser cost
> > than not being able to use the index until all live transactions exit.
> 
> 
> What I am proposing is to keep index unusable for existing transactions.
> The index is available for all new transactions even if there are unfinished
> existing transactions. Is that a big problem ? Well, I still need buy-in and
> review from Tom and others on the design, but it seems workable to me.

Yes, that seems totally acceptable to me.  As I remember, the index is
usable by the transaction that created it, and new transactions.  Hard
to see how someone would have a problem with that.

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

In response to

Responses

pgsql-hackers by date

Next:From: Merlin MoncureDate: 2007-03-29 18:02:36
Subject: Re: Fixing insecure security definer functions
Previous:From: August ZajoncDate: 2007-03-29 17:49:06
Subject: Re: Patch queue concern

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