From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Daniel Farina <drfarina(at)acm(dot)org>, Jeff Davis <pgsql(at)j-davis(dot)com>, David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Refactoring the Type System |
Date: | 2010-11-15 02:37:13 |
Message-ID: | AANLkTimmVZKwuo6KOxnUtpASRPf-TkRS4FpeyH4=ATXE@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Nov 14, 2010 at 9:16 PM, Greg Stark <gsstark(at)mit(dot)edu> wrote:
> On Sun, Nov 14, 2010 at 11:15 AM, Daniel Farina <drfarina(at)acm(dot)org> wrote:
>> SUM(int2) => int4
>> SUM(int4) => int8
>> SUM(int8) => numeric
>>
>> Some weaknesses:
>>
>> SUM, of any precision, assumes that the precision being accumulated
>> into (which is also the return-precision) is enough to avoid overflow.
>> This is generally the case, but there's no reason why it *must* be
>> true. I'm especially looking at the int2 to int4 conversion. One could
>> imagine a more interesting scenario where overflow behavior could
>> occur much more easily.
>
> Fwiw I think he's right that sum(int2) should perhaps be redefined to
> return int8. As it stands all it would take is a 64k rows to
> potentially overflow. It's not super likely but it is plausible and
> the performance penalty to use int8 wouldn't be super big either.
>
> int4 doesn't seem like as realistic a problem since it would take 4
> billion rows and the performance penalty for using numeric would be
> much higher.
I think you could get the same effect by removing sum(int2)
altogether, which I wouldn't lose any sleep over.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-11-15 02:50:25 | Re: contrib: auth_delay module |
Previous Message | Robert Haas | 2010-11-15 02:34:23 | Re: Fix for cube picksplit function |