From f8fe328c24f15ccb8cc7655bb75ef2a299934518 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Wed, 13 Sep 2006 23:42:26 +0000 Subject: Some small editorialization on the description of CREATE INDEX CONCURRENTLY. Greg Stark, some further tweaks by me. --- doc/src/sgml/ref/create_index.sgml | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) (limited to 'doc/src/sgml/ref') diff --git a/doc/src/sgml/ref/create_index.sgml b/doc/src/sgml/ref/create_index.sgml index be0ca63f2c5..d89a553a86f 100644 --- a/doc/src/sgml/ref/create_index.sgml +++ b/doc/src/sgml/ref/create_index.sgml @@ -1,5 +1,5 @@ @@ -264,22 +264,19 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] name - Creating an index for a large table can be a long operation. In large data - warehousing applications it can easily take hours or even days to build - indexes. It's important to understand the impact creating indexes has on a - system. - - - + Creating an index can interfere with regular operation of a database. Normally PostgreSQL locks the table to be indexed against writes and performs the entire index build with a single scan of the table. Other transactions can still read the table, but if they try to insert, update, or delete rows in the table they will block until the - index build is finished. + index build is finished. This could have a severe effect if the system is + a live production database. Large tables can take many hours to be + indexed, and even for smaller tables, an index build can lock out writers + for periods that are unacceptably long for a production system. - PostgreSQL also supports building indexes without locking + PostgreSQL supports building indexes without locking out writes. This method is invoked by specifying the CONCURRENTLY option of CREATE INDEX. When this option is used, -- cgit v1.2.3