Re: CREATE INDEX and HOT - revised design

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, "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 16:42:04
Message-ID: 873b3odmsj.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> 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
> way CREATE INDEX CONCURRENTLY does it...

I'm a bit skeptical about the idea of CREATE INDEX (ie, non-concurrent)
creating an index that won't be used for a while. We get enough people asking
why Postgres isn't using an index as it is... Besides, it seems if people are
happy to have indexes take a long time to build they could just do a
concurrent build. The reason they do non-concurrent builds is precisely
because they're willing to take an exclusive lock in order to have them
complete as soon as possible.

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.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-03-29 16:57:29 Re: Group Commit
Previous Message Heikki Linnakangas 2007-03-29 16:41:46 Re: Group Commit