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
Re: proposed TODO: non-locking CREATE INDEX / REINDEX |
Список | 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 по дате отправления: