Ambil catatan yang bukan nol setelah titik desimal di PostgreSQL

numeric tepat!

Tidak seperti yang diklaim oleh jawaban lain, numeric bukan tipe floating-point , tetapi tipe presisi arbitrer seperti yang didefinisikan oleh standar SQL. Penyimpanan tepat . Saya mengutip manualnya:

Tipe numerik dapat menyimpan angka dengan jumlah digit yang sangat banyak dan melakukan perhitungan dengan tepat. Sangat disarankan untuk menyimpan jumlah uang dan jumlah lain yang membutuhkan ketelitian.

Jawab

Kandidat alami untuk pertanyaan Anda adalah fungsi trunc() . Ini memotong menuju nol - pada dasarnya menjaga bagian integer sambil membuang sisanya. Tercepat dalam tes cepat, tetapi perbedaannya tidak signifikan di antara pesaing teratas.

SELECT * FROM t WHERE amount <> trunc(amount);

floor() terpotong ke bilangan bulat yang lebih rendah berikutnya, yang membuat perbedaan dengan angka negatif:

SELECT * FROM t WHERE amount <> floor(amount);

Jika nomor Anda cocok dengan integer / bigint Anda juga dapat melakukan cast:

SELECT * FROM t WHERE amount <> amount::bigint;

Ini putaran ke angka penuh, tidak seperti di atas.

Uji

Diuji dengan PostgreSQL 9.1.7. Tabel sementara dengan 10rb numeric angka dengan dua digit pecahan, sekitar 1% memiliki .00 .

CREATE TEMP TABLE t(amount) AS
SELECT round((random() * generate_series (1,10000))::numeric, 2);

Hasil yang benar dalam kasus saya:9890 baris. Waktu terbaik dari 10 run dengan EXPLAIN ANALYZE .

Erwin 1

SELECT count(*) FROM t WHERE amount <> trunc(amount)          -- 43.129 ms

mvp 2 / qqx

SELECT count(*) FROM t WHERE amount != round(amount)          -- 43.406 ms

Erwin 3

SELECT count(*) FROM t WHERE amount <> amount::int            -- 43.668 ms

mvp 1

SELECT count(*) FROM t WHERE round(amount,2) != round(amount) -- 44.144 ms

Erwin 4

SELECT count(*) FROM t WHERE amount <> amount::bigint         -- 44.149 ms

Erwin 2

SELECT count(*) FROM t WHERE amount <> floor(amount)          -- 44.918 ms

Nandakumar V

SELECT count(*) FROM t WHERE amount - floor(amount) > .00     -- 46.640 ms

Sebagian besar masih benar di Postgres 12 (kecuali semuanya> 10x lebih cepat sekarang). Uji dengan 100rb baris, bukan 10rb:

db<>main biola di sini