mirror of
https://git.postgresql.org/git/postgresql.git
synced 2026-02-12 17:37:07 +08:00
02ddd49932
Previously, floating-point output was done by rounding to a specific decimal precision; by default, to 6 or 15 decimal digits (losing information) or as requested using extra_float_digits. Drivers that wanted exact float values, and applications like pg_dump that must preserve values exactly, set extra_float_digits=3 (or sometimes 2 for historical reasons, though this isn't enough for float4). Unfortunately, decimal rounded output is slow enough to become a noticable bottleneck when dealing with large result sets or COPY of large tables when many floating-point values are involved. Floating-point output can be done much faster when the output is not rounded to a specific decimal length, but rather is chosen as the shortest decimal representation that is closer to the original float value than to any other value representable in the same precision. The recently published Ryu algorithm by Ulf Adams is both relatively simple and remarkably fast. Accordingly, change float4out/float8out to output shortest decimal representations if extra_float_digits is greater than 0, and make that the new default. Applications that need rounded output can set extra_float_digits back to 0 or below, and take the resulting performance hit. We make one concession to portability for systems with buggy floating-point input: we do not output decimal values that fall exactly halfway between adjacent representable binary values (which would rely on the reader doing round-to-nearest-even correctly). This is known to be a problem at least for VS2013 on Windows. Our version of the Ryu code originates from https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the following (significant) modifications: - Output format is changed to use fixed-point notation for small exponents, as printf would, and also to use lowercase 'e', a minimum of 2 exponent digits, and a mandatory sign on the exponent, to keep the formatting as close as possible to previous output. - The output of exact midpoint values is disabled as noted above. - The integer fast-path code is changed somewhat (since we have fixed-point output and the upstream did not). - Our project style has been largely applied to the code with the exception of C99 declaration-after-statement, which has been retained as an exception to our present policy. - Most of upstream's debugging and conditionals are removed, and we use our own configure tests to determine things like uint128 availability. Changing the float output format obviously affects a number of regression tests. This patch uses an explicit setting of extra_float_digits=0 for test output that is not expected to be exactly reproducible (e.g. due to numerical instability or differing algorithms for transcendental functions). Conversions from floats to numeric are unchanged by this patch. These may appear in index expressions and it is not yet clear whether any change should be made, so that can be left for another day. This patch assumes that the only supported floating point format is now IEEE format, and the documentation is updated to reflect that. Code by me, adapting the work of Ulf Adams and other contributors. References: https://dl.acm.org/citation.cfm?id=3192369 Reviewed-by: Tom Lane, Andres Freund, Donald Dong Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
117 lines
3.8 KiB
SQL
117 lines
3.8 KiB
SQL
--
|
|
-- POINT
|
|
--
|
|
|
|
-- avoid bit-exact output here because operations may not be bit-exact.
|
|
SET extra_float_digits = 0;
|
|
|
|
CREATE TABLE POINT_TBL(f1 point);
|
|
|
|
INSERT INTO POINT_TBL(f1) VALUES ('(0.0,0.0)');
|
|
|
|
INSERT INTO POINT_TBL(f1) VALUES ('(-10.0,0.0)');
|
|
|
|
INSERT INTO POINT_TBL(f1) VALUES ('(-3.0,4.0)');
|
|
|
|
INSERT INTO POINT_TBL(f1) VALUES ('(5.1, 34.5)');
|
|
|
|
INSERT INTO POINT_TBL(f1) VALUES ('(-5.0,-12.0)');
|
|
|
|
INSERT INTO POINT_TBL(f1) VALUES ('(1e-300,-1e-300)'); -- To underflow
|
|
|
|
INSERT INTO POINT_TBL(f1) VALUES ('(1e+300,Inf)'); -- To overflow
|
|
|
|
INSERT INTO POINT_TBL(f1) VALUES (' ( Nan , NaN ) ');
|
|
|
|
-- bad format points
|
|
INSERT INTO POINT_TBL(f1) VALUES ('asdfasdf');
|
|
|
|
INSERT INTO POINT_TBL(f1) VALUES ('10.0,10.0');
|
|
|
|
INSERT INTO POINT_TBL(f1) VALUES ('(10.0 10.0)');
|
|
|
|
INSERT INTO POINT_TBL(f1) VALUES ('(10.0, 10.0) x');
|
|
|
|
INSERT INTO POINT_TBL(f1) VALUES ('(10.0,10.0');
|
|
|
|
INSERT INTO POINT_TBL(f1) VALUES ('(10.0, 1e+500)'); -- Out of range
|
|
|
|
|
|
SELECT '' AS six, * FROM POINT_TBL;
|
|
|
|
-- left of
|
|
SELECT '' AS three, p.* FROM POINT_TBL p WHERE p.f1 << '(0.0, 0.0)';
|
|
|
|
-- right of
|
|
SELECT '' AS three, p.* FROM POINT_TBL p WHERE '(0.0,0.0)' >> p.f1;
|
|
|
|
-- above
|
|
SELECT '' AS one, p.* FROM POINT_TBL p WHERE '(0.0,0.0)' >^ p.f1;
|
|
|
|
-- below
|
|
SELECT '' AS one, p.* FROM POINT_TBL p WHERE p.f1 <^ '(0.0, 0.0)';
|
|
|
|
-- equal
|
|
SELECT '' AS one, p.* FROM POINT_TBL p WHERE p.f1 ~= '(5.1, 34.5)';
|
|
|
|
-- point in box
|
|
SELECT '' AS three, p.* FROM POINT_TBL p
|
|
WHERE p.f1 <@ box '(0,0,100,100)';
|
|
|
|
SELECT '' AS three, p.* FROM POINT_TBL p
|
|
WHERE box '(0,0,100,100)' @> p.f1;
|
|
|
|
SELECT '' AS three, p.* FROM POINT_TBL p
|
|
WHERE not p.f1 <@ box '(0,0,100,100)';
|
|
|
|
SELECT '' AS two, p.* FROM POINT_TBL p
|
|
WHERE p.f1 <@ path '[(0,0),(-10,0),(-10,10)]';
|
|
|
|
SELECT '' AS three, p.* FROM POINT_TBL p
|
|
WHERE not box '(0,0,100,100)' @> p.f1;
|
|
|
|
SELECT '' AS six, p.f1, p.f1 <-> point '(0,0)' AS dist
|
|
FROM POINT_TBL p
|
|
ORDER BY dist;
|
|
|
|
SELECT '' AS thirtysix, p1.f1 AS point1, p2.f1 AS point2, p1.f1 <-> p2.f1 AS dist
|
|
FROM POINT_TBL p1, POINT_TBL p2
|
|
ORDER BY dist, p1.f1[0], p2.f1[0];
|
|
|
|
SELECT '' AS thirty, p1.f1 AS point1, p2.f1 AS point2
|
|
FROM POINT_TBL p1, POINT_TBL p2
|
|
WHERE (p1.f1 <-> p2.f1) > 3;
|
|
|
|
-- put distance result into output to allow sorting with GEQ optimizer - tgl 97/05/10
|
|
SELECT '' AS fifteen, p1.f1 AS point1, p2.f1 AS point2, (p1.f1 <-> p2.f1) AS distance
|
|
FROM POINT_TBL p1, POINT_TBL p2
|
|
WHERE (p1.f1 <-> p2.f1) > 3 and p1.f1 << p2.f1
|
|
ORDER BY distance, p1.f1[0], p2.f1[0];
|
|
|
|
-- put distance result into output to allow sorting with GEQ optimizer - tgl 97/05/10
|
|
SELECT '' AS three, p1.f1 AS point1, p2.f1 AS point2, (p1.f1 <-> p2.f1) AS distance
|
|
FROM POINT_TBL p1, POINT_TBL p2
|
|
WHERE (p1.f1 <-> p2.f1) > 3 and p1.f1 << p2.f1 and p1.f1 >^ p2.f1
|
|
ORDER BY distance;
|
|
|
|
-- Test that GiST indexes provide same behavior as sequential scan
|
|
CREATE TEMP TABLE point_gist_tbl(f1 point);
|
|
INSERT INTO point_gist_tbl SELECT '(0,0)' FROM generate_series(0,1000);
|
|
CREATE INDEX point_gist_tbl_index ON point_gist_tbl USING gist (f1);
|
|
INSERT INTO point_gist_tbl VALUES ('(0.0000009,0.0000009)');
|
|
SET enable_seqscan TO true;
|
|
SET enable_indexscan TO false;
|
|
SET enable_bitmapscan TO false;
|
|
SELECT COUNT(*) FROM point_gist_tbl WHERE f1 ~= '(0.0000009,0.0000009)'::point;
|
|
SELECT COUNT(*) FROM point_gist_tbl WHERE f1 <@ '(0.0000009,0.0000009),(0.0000009,0.0000009)'::box;
|
|
SELECT COUNT(*) FROM point_gist_tbl WHERE f1 ~= '(0.0000018,0.0000018)'::point;
|
|
SET enable_seqscan TO false;
|
|
SET enable_indexscan TO true;
|
|
SET enable_bitmapscan TO true;
|
|
SELECT COUNT(*) FROM point_gist_tbl WHERE f1 ~= '(0.0000009,0.0000009)'::point;
|
|
SELECT COUNT(*) FROM point_gist_tbl WHERE f1 <@ '(0.0000009,0.0000009),(0.0000009,0.0000009)'::box;
|
|
SELECT COUNT(*) FROM point_gist_tbl WHERE f1 ~= '(0.0000018,0.0000018)'::point;
|
|
RESET enable_seqscan;
|
|
RESET enable_indexscan;
|
|
RESET enable_bitmapscan;
|