- /*
- * We do a concurrent index build by first inserting the catalog entry for the
- * index via index_create(),marking it not indisready and not indisvalid.
- * Then we commit our transaction and start a new one,then we wait for all
- * transactions that could have been modifying the table to terminate. Now
- * we know that any subsequently-started transactions will see the index and
- * honor its constraints on HOT updates; so while existing HOT-chains might
- * be broken with respect to the index,no currently live tuple will have an
- * incompatible HOT update done to it. We now build the index normally via
- * index_build(),while holding a weak lock that allows concurrent
- * insert/update/delete. Also,we index only tuples that are valid
- * as of the start of the scan (see IndexBuildHeapScan),whereas a normal
- * build takes care to include recently-dead tuples. This is OK because
- * we won't mark the index valid until all transactions that might be able
- * to see those tuples are gone. The reason for doing that is to avoid
- * bogus unique-index failures due to concurrent UPDATEs (we might see
- * different versions of the same row as being valid when we pass over them,* if we used HeapTupleSatisfiesVacuum). This leaves us with an index that
- * does not contain any tuples added to the table while we built the index.
- * For a concurrent build,it's important to make the catalog entries
- * visible to other transactions before we start to build the index. That
- * will prevent them from making incompatible HOT updates.The new index
- * will be marked not indisready and not indisvalid,so that no one else
- * tries to either insert into it or use it for queries.
- */
普通的create index是当建index时,不充许对表进行更改,postgresql支持的Concurrent创建index,是充分在建索引时同时对表进行更改。
共用了三个事务。
第一个事务,只是在系统表中增加索引定义,不建索引,索引不能insert,也不能select
第二个事务,创建索引,创建过程中充许对表insert/update/delete,提交时,索引可以insert,不能select.
第三个事务,把第二个事务过程中,没加入索引中的,合并进索引。
http://www.postgresql.org/docs/9.1/static/sql-createindex.html#SQL-CREATEINDEX-CONCURRENTLY