Re: [HACKERS] Current int & float overflow checking is slow. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Current int & float overflow checking is slow.
Date
Msg-id 22057.1508854149@sss.pgh.pa.us
Whole thread Raw
In response to [HACKERS] Current int & float overflow checking is slow.  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] Current int & float overflow checking is slow.
List pgsql-hackers
Andres Freund <andres@anarazel.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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] Remove secondary checkpoint
Next
From: Gaddam Sai Ram
Date:
Subject: [HACKERS] CurTransactionContext freed before transaction COMMIT ???