From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Matt Pulver <mpulver(at)unitytechgroup(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Infinity vs Error for division by zero |
Date: | 2019-03-01 18:26:05 |
Message-ID: | 20190301182605.f66tcmkoyvfmewxf@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2019-03-01 11:04:04 -0700, David G. Johnston wrote:
> Changing the behavior is not going to happen for any existing data types.
For the overflow case that really sucks, because we're leaving a very
significant amount of performance on the table because we recheck for
overflow in every op. The actual float operation is basically free, but
the overflow check and the calling convention is not. JIT can get of the
latter, but not the former. Which is why we spend like 30% in one of the
TPCH queries doing overflow checks...
I still kinda wonder whether we can make trapping operations work, but
it's not trivial.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2019-03-01 18:43:35 | Re: reloption to prevent VACUUM from truncating empty pages at the end of relation |
Previous Message | Chapman Flack | 2019-03-01 18:23:54 | Re: Infinity vs Error for division by zero |