|
1 | 1 | <!-- |
2 | | -$PostgreSQL: pgsql/doc/src/sgml/indexam.sgml,v 2.3 2005/03/27 23:52:51 tgl Exp $ |
| 2 | +$PostgreSQL: pgsql/doc/src/sgml/indexam.sgml,v 2.4 2005/04/20 22:19:58 tgl Exp $ |
3 | 3 | --> |
4 | 4 |
|
5 | 5 | <chapter id="indexam"> |
@@ -109,7 +109,8 @@ $PostgreSQL: pgsql/doc/src/sgml/indexam.sgml,v 2.3 2005/03/27 23:52:51 tgl Exp $ |
109 | 109 | such a scan should include null rows. In practice this means that |
110 | 110 | indexes that support ordered scans (have <structfield>amorderstrategy</> |
111 | 111 | nonzero) must index nulls, since the planner might decide to use such a |
112 | | - scan as a substitute for sorting. Another restriction is that an index |
| 112 | + scan as a substitute for sorting. Such indexes must also be willing to |
| 113 | + run a scan with no scan keys at all. Another restriction is that an index |
113 | 114 | access method that supports multiple index columns <emphasis>must</> |
114 | 115 | support indexing null values in columns after the first, because the planner |
115 | 116 | will assume the index can be used for queries on just the first |
|