|
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