Tìm nạp các bản ghi khác 0 sau dấu thập phân trong PostgreSQL

numeric là chính xác!

Không giống như được xác nhận bởi một câu trả lời khác, numeric không phải là loại dấu phẩy động , nhưng là loại chính xác tùy ý theo định nghĩa của tiêu chuẩn SQL. Bộ nhớ là chính xác . Tôi trích dẫn sách hướng dẫn:

Kiểu số có thể lưu trữ các số với một số lượng rất lớn các chữ số và thực hiện các phép tính một cách chính xác. Đặc biệt khuyến nghị nên tích trữ các số tiền và các số lượng khác khi yêu cầu độ chính xác.

Trả lời

Ứng cử viên tự nhiên cho câu hỏi của bạn là hàm trunc() . Nó cắt ngắn về không - Về cơ bản giữ phần nguyên trong khi loại bỏ phần còn lại. Nhanh nhất trong một thử nghiệm nhanh, nhưng sự khác biệt là không đáng kể giữa các ứng cử viên hàng đầu.

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

floor() cắt ngắn thành số nguyên thấp hơn tiếp theo, điều này tạo ra sự khác biệt với số âm:

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

Nếu các số của bạn vừa với integer / bigint bạn cũng có thể chỉ truyền:

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

vòng này thành số đầy đủ, không giống như ở trên.

Kiểm tra

Đã thử nghiệm với PostgreSQL 9.1.7. Bảng tạm thời có 10k numeric các số có hai chữ số thập phân, khoảng 1% có .00 .

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

Kết quả đúng trong trường hợp của tôi:9890 hàng. Thời gian tốt nhất từ ​​10 lần chạy với 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

Hầu hết vẫn đúng trong Postgres 12 (ngoại trừ mọi thứ hiện nhanh hơn> 10 lần). Thử nghiệm với 100k hàng thay vì 10k:

db <> fiddle here