It seems that currently we do not allow modifying a table while an index
is built on it (at least my experience and some small tests I did
indicate it). Strangely I did not find a TODO item for it, so I may be
overlooking something and we already have it.
In case we really all
For big 24/7 tables this can be a real annoyance, especially in an
evolving database.
There are many ways this could be made to work, so it needs some
discussion.
I propose the following approach:
1) when CREATE INDEX starts a ctid position (CTID_INDEX_MIN) of last
tuple is remembered and all new tuples are inserted after that point
while an index is being built.
2) the index is built in the usual fast way up to the remembered ctid,
and make it visible for all backends for inserting, but not yet to
planner for using. we remember the last ctid inserted while the fast-
build phase was running (CTID_INDEX_MAX). the restriction to add new
tuples only after CTID_INDEX_MIN is lifted.
3) then add index entries for all tuples whose ctid is between
CTID_INDEX_MIN and CTID_INDEX_MAX.
4) declare the index usable for planner.
Additionally CREATE INDEX could be made to honour vacuum_cost_*
variables and not hog busy database.
--
Hannu Krosing <[EMAIL PROTECTED]>
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
