Re: Current int & float overflow checking is slow.
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-10-25T05:53:49Z
Lists: pgsql-hackers
On 2017-10-25 07:33:46 +0200, Robert Haas wrote: > On Tue, Oct 24, 2017 at 9:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > I don't like changing well-defined, user-visible query behavior for > > no other reason than a performance gain (of a size that hasn't even > > been shown to be interesting, btw). Will we change it back in another > > ten years if the performance tradeoff changes? That part of the argument seems unconvincing. It's not like the overflow check is likely to ever have been beneficial performancewise, nor is it remotely likely for that to ever be the case. > > Also, if I recall the old discussion properly, one concern was getting > > uniform behavior across different platforms. I'm worried that if we do > > what Andres suggests, we'll get behavior that is not only different but > > platform-specific. Now, to the extent that you believe that every modern > > platform implements edge-case IEEE float behavior the same way, that worry > > may be obsolete. But I don't think I believe that. > > Yeah, those are reasonable concerns. I agree. I'm not really sure what the right way is here. I do however think it's worth discussing what ways to address the performance penalty due to the overflow checks, and one obvious way to do so is not to play. It'd be interesting to write the overflow checking addition in x86 inline asm, and see how much better that gets - just so we know the maximum we can reach with that. The problem with the C99 stuff seems to be the external function calls. With either, one problem would be that we'd have to reset the overflow register before doing math, which isn't free either - otherwise some external function could have left it set to on. Greetings, Andres Freund
Commits
-
Provide overflow safe integer math inline functions.
- 4d6ad31257ad 11.0 landed
-
Use new overflow aware integer operations.
- 101c7ee3ee84 11.0 landed