|
1 | 1 | <!-- |
2 | | -$PostgreSQL: pgsql/doc/src/sgml/ref/create_index.sgml,v 1.56 2006/08/25 04:06:45 tgl Exp $ |
| 2 | +$PostgreSQL: pgsql/doc/src/sgml/ref/create_index.sgml,v 1.57 2006/09/13 23:42:26 tgl Exp $ |
3 | 3 | PostgreSQL documentation |
4 | 4 | --> |
5 | 5 |
|
@@ -264,22 +264,19 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] <replaceable class="parameter">name</re |
264 | 264 | </indexterm> |
265 | 265 |
|
266 | 266 | <para> |
267 | | - Creating an index for a large table can be a long operation. In large data |
268 | | - warehousing applications it can easily take hours or even days to build |
269 | | - indexes. It's important to understand the impact creating indexes has on a |
270 | | - system. |
271 | | - </para> |
272 | | - |
273 | | - <para> |
| 267 | + Creating an index can interfere with regular operation of a database. |
274 | 268 | Normally <productname>PostgreSQL</> locks the table to be indexed against |
275 | 269 | writes and performs the entire index build with a single scan of the |
276 | 270 | table. Other transactions can still read the table, but if they try to |
277 | 271 | insert, update, or delete rows in the table they will block until the |
278 | | - index build is finished. |
| 272 | + index build is finished. This could have a severe effect if the system is |
| 273 | + a live production database. Large tables can take many hours to be |
| 274 | + indexed, and even for smaller tables, an index build can lock out writers |
| 275 | + for periods that are unacceptably long for a production system. |
279 | 276 | </para> |
280 | 277 |
|
281 | 278 | <para> |
282 | | - <productname>PostgreSQL</> also supports building indexes without locking |
| 279 | + <productname>PostgreSQL</> supports building indexes without locking |
283 | 280 | out writes. This method is invoked by specifying the |
284 | 281 | <literal>CONCURRENTLY</> option of <command>CREATE INDEX</>. |
285 | 282 | When this option is used, |
|
0 commit comments