Re: proposed TODO: non-locking CREATE INDEX / REINDEX

Поиск
Список
Период
Сортировка
От Hannu Krosing
Тема Re: proposed TODO: non-locking CREATE INDEX / REINDEX
Дата
Msg-id 1118415252.4972.27.camel@fuji.krosing.net
обсуждение исходный текст
Ответ на Re: proposed TODO: non-locking CREATE INDEX / REINDEX  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: proposed TODO: non-locking CREATE INDEX / REINDEX  (Hannu Krosing <hannu@tm.ee>)
Re: proposed TODO: non-locking CREATE INDEX / REINDEX  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On R, 2005-06-10 at 09:47 -0400, Tom Lane wrote:
> Hannu Krosing <hannu@skype.net> writes:
> > There are many ways this could be made to work, so it needs some
> > discussion.
> 
> (1) when do you ever catch up?
>
> (2) if your answer to (1) involves increasing the strength of a lock,
>     how do you avoid risk of deadlock?

No. I don't plan on locking the table at all. 

The only thing that is changed during the initial fast-build-index is
that new tuples are inserted after CTID_INDEX_MIN, and after the initial
fastbuild index is done, the only restriction is that the index can't be
used in queries before the tuples between  CTID_INDEX_MIN and
CTID_INDEX_MAX are added to the index.

As the number of tuples between CTID_INDEX_MIN and CTID_INDEX_MAX is
finite, they must be added in finite time, by which time the index will
be up-to-date and usable for querie planner. (i.e. (1) is done)

All tuples inserted after the initial fast-build-index has finished and
CTID_INDEX_MAX is fixed, are inserted into the index at the time of
inserting the tuple, like for any other index.

-- 
Hannu Krosing <hannu@skype.net>



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

Предыдущее
От: Yann Michel
Дата:
Сообщение: Re: User Quota Implementation
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: proposed TODO: non-locking CREATE INDEX / REINDEX