proposed TODO: non-locking CREATE INDEX / REINDEX

From: Hannu Krosing <hannu(at)skype(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: proposed TODO: non-locking CREATE INDEX / REINDEX
Date: 2005-06-10 08:33:54
Message-ID: 1118392435.4972.13.camel@fuji.krosing.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 <hannu(at)skype(dot)net>

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Pflug 2005-06-10 09:32:29 Server instrumentation
Previous Message Yann Michel 2005-06-10 08:06:00 Re: User Quota Implementation