Commit 1c155c8d authored by Tom Lane's avatar Tom Lane

Add note clarifying that indexes that support ordered scans had better

allow clauseless scans.
parent eb4f58ad
<!-- <!--
$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"> <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,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 such a scan should include null rows. In practice this means that
indexes that support ordered scans (have <structfield>amorderstrategy</> indexes that support ordered scans (have <structfield>amorderstrategy</>
nonzero) must index nulls, since the planner might decide to use such a 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</> access method that supports multiple index columns <emphasis>must</>
support indexing null values in columns after the first, because the planner 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 will assume the index can be used for queries on just the first
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment