Users accustomed to working with other SQL database management
- systems may be surprised by the performance characteristics of
- certain aggregate functions in
-
PostgreSQL when the aggregate is
- applied to the entire table (in other words, no
- WHERE clause is specified). In particular, a
- query like
+ systems may be surprised by the performance of the
+ count aggregate when it is applied to the
+ entire table. A query like:
-SELECT min(col) FROM sometable;
+SELECT count(*) FROM sometable;
will be executed by
PostgreSQL using a
- sequential scan of the entire table. Other database systems may
- optimize queries of this form to use an index on the column, if
- one is available. Similarly, the aggregate functions
- max() and count() always
- require a sequential scan if applied to the entire table in
-
-
-
PostgreSQL cannot easily implement this
- optimization because it also allows for user-defined aggregate
- queries. Since min(),
- max(), and count() are
- defined using a generic API for aggregate functions, there is no
- provision for special-casing the execution of these functions
- under certain circumstances.
-
-
- Fortunately, there is a simple workaround for
- min() and max(). The
- query shown below is equivalent to the query above, except that it
- can take advantage of a B-tree index if there is one present on
- the column in question.
-SELECT col FROM sometable ORDER BY col ASC LIMIT 1;
-
- A similar query (obtained by substituting DESC
- for ASC in the query above) can be used in the
- place of max().
-
-
- Unfortunately, there is no similarly trivial workaround that can
- be used to improve the performance of count()
- when applied to the entire table.
+ sequential scan of the entire table.
-