On R, 2005-06-10 at 17:54 +0300, Hannu Krosing wrote: > On R, 2005-06-10 at 09:47 -0400, Tom Lane wrote: > > Hannu Krosing <[EMAIL PROTECTED]> 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.
Maybe I did not make it very clear, but the initial fast-build-index is done only for the tuples whose ctid is below CTID_INDEX_MIN, thereby this also will happen in finite amount of time. The total time will be: initial_index_build_time + inserting_tuples_added_while_doing_the_initial_build the latter wil be slowed down a little, as these are competing with index entries from inserts happening in real time. > 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 <[EMAIL PROTECTED]> ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org