Re: Refactoring the Type System

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

In response to

Browse pgsql-hackers by date

  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