exec: overflow handling for aggregates

[jordanlewis]

Aggregates in vectorized currently don't check for overflows. This is incorrect and needs to be fixed.

[rafiss]

I'm wondering what we want to do with float overflow. Our current non-vectorized implementation already differs from Postgres.

Postgres:

rafiss@127:postgres> create table foo (b double precision primary key, c int);
CREATE TABLE

rafiss@127:postgres> insert into foo values(1.79769313486231570814527423737043567981e+308);
INSERT 0 1

rafiss@127:postgres> insert into foo values(1.79769313486231570814527423737043567981e+307);
INSERT 0 1

rafiss@127:postgres> select * from foo;
+-----------------------+--------+
| b                     | c      |
|-----------------------+--------|
| inf                   | <null> |
| 1.79769313486232e+307 | <null> |
+-----------------------+--------+
SELECT 2

rafiss@127:postgres> select avg(b) from foo;
2019-07-18 11:38:26.009 EDT [85826] ERROR:  value out of range: overflow
2019-07-18 11:38:26.009 EDT [85826] STATEMENT:  select avg(b) from foo
value out of range: overflow

CRDB 19.1

[email protected]:64470/defaultdb> create table foo (b float primary key);
CREATE TABLE

[email protected]:64561/defaultdb> insert into foo values(1.79769313486231570814527423737043567981e+308);
INSERT 1

[email protected]:64561/defaultdb> insert into foo values(1.79769313486231570814527423737043567981e+307);
INSERT 1

[email protected]:64561/defaultdb> select * from foo;
             b
+-------------------------+
  1.7976931348623158e+307
  1.7976931348623157e+308
(2 rows)

[email protected]:64561/defaultdb> select avg(b) from foo;
  avg
+------+
  +Inf
(1 row)

[jordanlewis]

Are we promoting float to decimal in that latter case?

[rafiss]

No, we are not promoting in that case. (We also see the same behavior as that latter case in the vectorized engine as it is right now.)

[jordanlewis]

I think this difference is probably acceptable at least for now - we already do it, plus it's pretty well-defined - it doesn't wrap around. YIL this is called "saturating" overflow behavior.

[maddyblue]

Yes, I discovered our float difference while writing edge. I decided it's fine because the behavior is the same as you would get if you were adding two large floats together (infinity). Actually thinking this through more...there's a good argument that while sum can return infinity, avg shouldn't. Hmm. Well at least we have tests asserting the results now.