列の数値と整数-サイズとパフォーマンス


11

PostgreSQLテーブルを使用するアプリケーションがあります。テーブルは非常に大きく(数十億行)、整数の列があります。

integerは最大6桁、つまり0〜999,999で、負の数は使用できません。

に変えることを考えましたnumeric(6,0)

これは良い考えでしょうか?うnumeric(6,0)少ないバイトを取りますか?パフォーマンスはどうですか(このテーブルは頻繁にクエリされます)?

回答:


11

これは良い考えでしょうか?

番号。

numeric(6,0)より少ないバイトを取るでしょうか?

番号。

test=> SELECT pg_column_size(INT4 '999999'), pg_column_size(NUMERIC(6,0) '999999');
 pg_column_size | pg_column_size 
----------------+----------------
              4 |             10
(1 row)

パフォーマンスはどうですか(このテーブルは頻繁に照会されます)?

もっとゆっくり。任意の精度値であるため、2進化10進数として格納されます。


サイドノートの数値には0〜999999のドメインが自動的に適用されるため、利点は1つあります。ただし、これはintケースの別の制約で解決できます
Lennart

1
numeric列をに変更する際に問題はあり intますか?
レーサーSQL

@RacerSQLはい、intサイズをオーバーフローする値がある場合。
DylanYoung

5

決定的な答えはあなたの質問すべてにノーです。整数は常に、それを使用できるものなら何でも利用できる方法です。(例えば、お金)

少し考えてみてください。データベースエンジンは、整数を検出すると、解釈が少ないため、非常に効率的に処理します。整数です。数値型は文字列のように動作します。エンジンは、最初に小数点の前後の部分を把握し、それらを適切にマッサージして数値演算を実行する必要があります。

人間にとっては数値型の方が便利ですが、整数を使用する方が常に数値よりも効率的です。


お金に関しては私は同意しません。デシセント(1ドルあたり1000)を格納するなど、スケーリングされた整数を使用することは問題ありませんが、扱いにくいものです。すぐに使いやすくなりますNUMERIC。スケーリングされた整数は、お金のために浮動小数点値を使用するよりもはるかに優れています。
クレイグリンガー

2
@CraigRinger私はあなたが実際に私に同意しないとは思わない!お金に小数を使用することは、開発者にとって常に厄介ではないことに同意しますが、問題はクエリの効率ですよね?整数の処理は常に高速です。また、銀行アプリケーションを作成するとき、ほとんどの人が気にしないが、銀行にとって非常に重要である奇妙な丸め問題に遭遇する可能性があります。それで、私も浮動小数点をお金に使わないことに同意します!
stubsthewizard 2015

1
丸めの良い点。PostgreSQLが丸めポリシーをサポートしてくれることを願っています。それを実装するのに十分にそれを望まないでください;)
クレイグリンガー
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.