| From: | Jochem van Dieten <jochemd(at)gmail(dot)com> |
|---|---|
| To: | Hannu Krosing <hannu(at)skype(dot)net> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <gsstark(at)mit(dot)edu>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking overhead) |
| Date: | 2005-12-06 19:50:45 |
| Message-ID: | f96a9b830512061150s396ed593s6187e04a9bd4ff5e@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 12/5/05, Hannu Krosing wrote:
>
> Concurrent CREATE INDEX
> ========================
>
> Concurrent index NDX1 on table TAB1 is created like this:
>
> 1) start transaction. take a snapshot SNAP1
>
> 1.1) optionally, remove pages for TAB1 from FSM to force (?) all newer
> inserts/updates to happen at end of table (won't work for in-page
> updates without code changes)
>
> 2) create the index as we do now, but only for pages which are visible
> in SNAP1
>
> 3) record the index in pg_class, but mark it as "do not use for lookups"
> in a new field. Take snapshot SNAP2. commit transaction.
What happens if another transaction takes a snapshot between SNAP2 and
the commit? Wouldn't you need a lock to guard against that? (Not that
I don't know if that is possible or desirable.)
Jochem
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rick Gigger | 2005-12-06 19:53:47 | Re: Replication on the backend |
| Previous Message | Michael Meskes | 2005-12-06 19:49:13 | Re: Replication on the backend |