Re: Refactoring the Type System

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 05:26:48
Message-ID: 22275.1289798808@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <gsstark(at)mit(dot)edu> writes:
> 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.

It's not unreasonable. I think the performance penalty for int8 was
higher when that choice was made than it is now --- and in particular,
on a 64-bit machine it's now pretty much negligible.

On the other hand, you can always execute sum(foo::int4) if you need a
wider sum, just like the escape hatch if any of the other datatype
choices aren't working for you. It's not clear that we should force a
performance loss on people who don't need it (and I can't offhand recall
*ever* hearing a complaint about sum(int2) overflowing...)

I believe what the OP was arguing for was not so much this sort of
marginal tinkering as inventing a more general notion of "integer type"
that would avoid the whole issue. The problem with that is that we have
to work within the set of types specified by the SQL standard.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2010-11-15 05:37:44 Re: MULTISET and additional functions for ARRAY
Previous Message Robert Haas 2010-11-15 04:39:33 changing MyDatabaseId