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