Re: Unexpected interval comparison
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: adrian.klaver@aklaver.com, frazer@frazermclean.co.uk,
pgsql-general@postgresql.org
Date: 2017-04-05T19:51:10Z
Lists: pgsql-general
Attachments
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes: > The attached patch is the revised version. Hmm, this still isn't right --- testing shows that you had the comparison rule right the first time. Looking at what we've got here, it's already a substantial fraction of what would be needed to provide a compiler-independent implementation of the int128-based aggregate logic in numeric.c. With that in mind, I propose that we extract the relevant stuff into a new header file that is designed as general-purpose int128 support. Something like the attached. I also attach the test program I put together to verify it. On my Fedora 25 laptop, it appears that the hand-rolled implementation is actually respectably fast compared to gcc's "native" functionality; the test program runs in ~2m for 1B iterations with the native logic, and ~2.5m with the hand-rolled logic. Allowing for overhead and the fact that we're doing the arithmetic twice, we're probably within 2X of the native code. Not bad at all. I'm not entirely sure what to do with the test program: 1. discard it 2. commit it as utils/adt/int128.c, as suggested in its comment 3. commit it somewhere else, maybe src/tools/. Thoughts? regards, tom lane
Commits
-
Fix integer-overflow problems in interval comparison.
- fd52b8834330 9.6.3 landed
- d68a2b20ae2c 9.5.7 landed
- 8851bcf8813b 9.4.12 landed
- df1a699e5ba3 10.0 landed