Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking overhead)

Поиск
Список
Период
Сортировка
От Jochem van Dieten
Тема Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking overhead)
Дата
Msg-id f96a9b830512061150s396ed593s6187e04a9bd4ff5e@mail.gmail.com
обсуждение исходный текст
Ответ на Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking overhead)  (Hannu Krosing <hannu@skype.net>)
Ответы Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking overhead)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing  (Hannu Krosing <hannu@skype.net>)
Список 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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Upcoming PG re-releases
Следующее
От: Michael Meskes
Дата:
Сообщение: Re: Replication on the backend