他のバージョンの文書 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

9.15. 集約関数

集約関数は複数の入力値から単一の結果を計算します。 表9-37に組み込み集約関数を示します。 集約関数の特殊な構文に関する考察は項4.2.7で説明されています。 その他の入門的な情報については、項2.7を参照してください。

表 9-37. 集約関数

関数引数のデータ型戻り値型説明
avg(expression) smallintintegerbigintrealdouble precisionnumericもしくはinterval 整数型の引数であれば全て numeric、浮動小数点の引数であれば double precision、それ以外は引数のデータ型と同じ 全ての入力値の平均値 (算術平均)
bit_and(expression) smallint, integer, bigint, もしくは、 bit 引数のデータ型と同じ 全ての非NULLの入力値のビット積、非NULLの入力値がなければNULL。
bit_or(expression) smallint, integer, bigint,もしくは、 bit 引数のデータ型と同じ 全ての非NULLの入力値のビット和、非NULLの入力値がなければNULL。
bool_and(expression) bool bool 全ての入力が真ならば真、さもなくば偽。
bool_or(expression) bool bool 少なくとも1つの入力値が真ならば真。さもなくば偽。
count(*) bigint入力値の総数
count(expression)全てbigintexpressionが非NULL値を持つ入力値の個数
every(expression) bool bool bool_andと等価です。
max(expression)数値型全て、string、date/time型のいずれか引数型と同一全ての入力値間でのexpressionの最大値
min(expression)数値型全て、string、date/time型のいずれか引数型と同一全ての入力値間でのexpressionの最小値
stddev(expression) smallintintegerbigintrealdouble precisionもしくはnumeric 浮動小数点の引数であればdouble precision、それ以外はnumeric 入力値の標本標準偏差
sum(expression)smallintintegerbigintrealdouble precisionnumericもしくはinterval smallintまたはinteger型の引数であればbigintbigint型の引数であればnumeric、浮動小数点の引数であればdouble precision、それ以外は引数のデータ型と同じ 全ての入力値に渡ってexpressionの和
variance(expression) smallintintegerbigintrealdouble precisionもしくはnumeric 浮動小数点の引数であればdouble precision、それ以外はnumeric 入力値の分散標本 (標本標準偏差の2乗)

上記の関数は、count関数を除き、1行も選択されなかった場合NULL値を返すことに注意してください。 特に、行の選択がないsum関数は、予想されるであろうゼロではなくNULLを返します。 必要であれば、NULLをゼロと交換する目的でcoalesce関数を使うことできます。

注意: bool_andbool_or論理集約関数は標準SQLの集約関数everyanyまたはsomeに対応します。 anysomeについてですが、標準の構文には曖昧さがあるようです。

SELECT b1 = ANY((SELECT b2 FROM t2 ...)) FROM t1 ...;

ここで、ANYは、副問い合わせの先頭とも、選択式が1行を返すとしたら集約関数とも取ることができます。 従って、標準ではこうした集約関数に名前がありません。

注意: 他のSQLデータベース管理システムでの作業に親しんだユーザは、集約がテーブル全体に適用される(言い替えるとWHERE句の指定がない)場合のPostgreSQLの集約関数の性能上の特徴に驚くかもしれません。 具体的には

SELECT min(col) FROM sometable;

という問い合わせは、PostgreSQLではテーブル全体に対するシーケンシャルスキャンを使用します。 他のデータベースシステムでは、この形式の問い合わせを列へのインデックスが使用できるのであればそれを使用するように、最適化する可能性があります。 同様に、PostgreSQLでは、テーブル全体に対するmax()およびcount()集約関数は常にシーケンシャルスキャンを要求します。

PostgreSQLでは、ユーザ定義の集約問い合わせを可能にするために、この最適化を簡単に実装することはできません。 min()max()およびcount()は集約関数用汎用APIを使用するように定義されているため、特定の環境下における関数実行に対して特別な処理をさせるための用意がありません。

幸いにも、min()およびmax()には簡単な回避方法があります。 以下の問い合わせは上の問い合わせと同じですが、もし問題の列にB-treeインデックスが存在する場合はそれを利用するという利点があります。

SELECT col FROM sometable ORDER BY col ASC LIMIT 1;

上の問い合わせでASCDESCで置き換えて得られる)同様の問い合わせを使用してmax()を代行することができます。

残念ながら、テーブル全体を対象としてcount()の性能を向上させるために使用できる、上同様の簡単な問い合わせはありません。