Re: Refactoring the Type System

On Sun, Nov 14, 2010 at 7:47 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Daniel Farina <drfarina(at)acm(dot)org> writes:
>> Here are some weaknesses in the SUM aggregate that run up against the
>> type system. Maybe they'll help crystallize some discussion:
>
>> 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 not a flaw of the type system, it's just an implementation
> choice in the SUM() aggregates.  We could easily have chosen wider
> accumulation and/or result types.

That's true, but there are downsides to escalating the precision so
aggressively.

The case I was thinking about in particular involves composition of
SUM. If one can assume that a relation has int4s and that will never
overflow an int8 (as is done now), I don't see a great way to optimize
the following case without special exceptions in the optimizer for
particular aggregates known a-priori. Here's what would happen now:

SELECT SUM(x::int8)::numeric
FROM (SELECT SUM(x::int4)::int8 AS x
FROM rel
GROUP BY y) some_name;

Could be rendered, by this assumption, as:

SELECT SUM(x::int8)::int8
....(same FROM clause)

(Why would anyone write a query like this? Views. Possibly inlined SQL
UDFs, too.)

This can be measurably faster. It also more properly constrains the
result type, as numeric can also handle non-integer quantities.

I should have underscored that a positive aspect of having a
type-class like facility that allows declaration things like this
hypothetical Integer when backed by concrete types that might support
a superset of functionality.

fdr