On Jan9, 2014, at 18:09 , Tom Lane <t...@sss.pgh.pa.us> wrote:
> Florian Pflug <f...@phlo.org> writes:
>> For float 4 and float8, wasn't the consensus that the potential
>> lossy-ness of addition makes this impossible anyway, even without the
>> NaN issue? But...
> Well, that was my opinion, I'm not sure if it was consensus ;-).

I'd say your example showing how it could produce completely bogus
results was pretty convincing...

> But NaN is an orthogonal problem I think.  I'm not sure whether it
> has analogues in other data types.

Transfer functions which are partially invertible are not that
uncommon, I'd say. Browsing through 9.3's list of aggregate functions,
the following come to mind

  Values smaller than the maximum can be removed, removing the current
  maximum requires a rescan. By remembering the N largest values,
  the number of required rescans can be reduced, but never fully
  eliminated. Same works for min().

  FALSE can be removed, removing TRUE requires a rescan. Could be made
  fully invertible by counting the number of TRUE and FALSE values,
  similar to my suggestion for how to handle NaN for sum(numeric).
  Same works for bool_and().

  Like boo_or(), 0 can be removed, everything else requires a rescan.
  Same works for bit_and()

Plus, any aggregate with a strict transfer function would be in
exactly the same situation regarding NULL as sum(numeric) is regarding
NaN. AFAIK we don't have any such aggregate in core, though.

best regards,
Florian Pflug

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

Reply via email to