On Fri, Jun 10, 2005 at 12:12:05PM -0400, Tom Lane wrote: > Hannu Krosing <[EMAIL PROTECTED]> writes: > > 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) > > ... and by which time, some more could have been added after > CTID_INDEX_MAX. Have you forgotten Zeno's paradox? I don't see a > reason to assume the indexer can *ever* catch up --- it's entirely > likely that adding a new unindexed row is faster than adding an index > entry for it. > > > 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. > > This implies that you are hoping for an asynchronous change in the > behavior of other processes, which you are not going to get without > taking out locks, which is what you wanted to avoid. >
Maybe I am misunderstanding something, but the scenario seems to be in the ever simpler pseudo-code: 1. Issue CREATE INDEX command 2. Record CTID_INDEX_MAX 3. Mark the index as created with the "FAST" flag. This means that all of the normal INSERT/DELETE processing with regards to the data tuples and the index tuples is performed. i.e. the new tuples cannot be added faster than the index because the insert of the data tuple does not commit until the index entries are added. 4. Start generating the index entries until you reach CTID_INDEX_MAX 5. Mark the index as LIVE. Ken Marshall ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
