Pavelはそれを正しく理解しています。少し説明したいと思います。
浮動小数点または固定小数点オフセット整数（つまり、1000分の1セントを整数として格納する）と比較した場合のパフォーマンスへの影響を意味すると仮定します。はい、パフォーマンスへの影響は非常に大きくなります。 PostgreSQL、そしてMySQLの音で、DECIMALを保存します / NUMERIC 2進化10進数。この形式は、数字をテキストとして保存するよりもコンパクトですが、それでも操作はあまり効率的ではありません。
データベースで多くの計算を行っていない場合、影響は整数または浮動小数点と比較してBCDに必要なストレージスペースが大きくなるため、行が広くなり、スキャンが遅くなり、インデックスが大きくなるなどに限定されます。 -ツリーインデックスの検索も遅くなりますが、他の理由ですでにCPUにバインドされていない限り、問題になるほどではありません。
DECIMALを使用して多くの計算を行っている場合 / NUMERIC データベース内の値の場合、パフォーマンスが大幅に低下する可能性があります。これは、少なくともPostgreSQLでは特に顕著です。これは、Pgが特定のクエリに複数のCPUを使用できないためです。数値に対して膨大な数の除算と乗算、より複雑な数学、集計などを実行している場合、浮動小数点または整数のデータ型を使用するときは決してない状況で、CPUに縛られていることに気付く可能性があります。これは、OLAPのような（分析）ワークロード、およびロードまたは抽出（ETL）中のレポートまたはデータ変換で特に顕著です。
があるという事実にもかかわらず パフォーマンスへの影響（ワークロードによって無視できるものから非常に大きいものまで変化します）は、通常、numericを使用する必要があります / decimal タスクに最も適切なタイプである場合、つまり、非常に高い範囲の値を格納する必要がある場合、および/または丸め誤差が許容されない場合。
時折、bigintと固定小数点オフセットを使用する手間をかける価値がありますが、それは不器用で柔軟性がありません。代わりに浮動小数点を使用することが正しい答えになることはめったにありません。通貨などの浮動小数点値を確実に処理するためのすべての課題があるためです。
（ところで、いくつかの新しいIntelCPUとIBMのPower7シリーズのCPUに、IEEE 754 10進浮動小数点のハードウェアサポートが含まれていることに非常に興奮しています。これがローエンドCPUで利用可能になれば、データベースにとって大きなメリットになります。 。）