Re: Current int & float overflow checking is slow.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Current int & float overflow checking is slow.
Date: 2017-10-24 14:09:09
Message-ID: 22057.1508854149@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> There's no comparable overflow handling to the above integer
> intrinsics. But I think we can still do a lot better. Two very different
> ways:

> 1) Just give up on detecting overflows for floats. Generating inf in
> these cases actually seems entirely reasonable. We already don't
> detect them in a bunch of cases anyway. I can't quite parse the
> standard's language around this.

There's an ancient saying that code can be arbitrarily fast if it
doesn't have to get the right answer. I think this proposal falls
in that category.

> 2) Use platform specific float exception handling where available. We
> could at backend start, and in FloatExceptionHandler(), us
> feenableexcept() (windows has similar) to trigger SIGFPE on float
> overflow.

SIGFPE isn't going to be easy to recover from, nor portable.

I think what you actually want to do is *disable* SIGFPE (see
feholdexcept), and then have individual functions use feclearexcept
and fetestexcept. These functions were standardized by C99 so
they should be pretty widely available ... of course, whether they
actually are widely portable remains to be seen. Whether they're
faster than what we're doing now also remains to be seen.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gaddam Sai Ram 2017-10-24 14:12:13 CurTransactionContext freed before transaction COMMIT ???
Previous Message Andres Freund 2017-10-24 13:55:35 Re: Remove secondary checkpoint