Hannu Krosing <hannu@skype.net> 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.
regards, tom lane
