Re: Using 128-bit integers for sum, avg and statistics aggregates

From: Andreas Karlsson <andreas(at)proxel(dot)se>
To: David Rowley <dgrowleyml(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Using 128-bit integers for sum, avg and statistics aggregates
Date: 2015-01-18 00:37:11
Message-ID: 54BB0037.5040207@proxel.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/31/2014 03:00 PM, David Rowley wrote:
> hmm, I think it should be changed to int128 then. Pitty int4 was
> selected as a name instead of int32 back in the day...
>
> I'm going to mark the patch as waiting on author, pending those two changes.
>
> My view with the size estimates change is that if a committer deems it
> overkill, then they can rip it out, but at least it's been thought of
> and considered rather than forgotten about.

Did we come to any conclusion about naming conventions?

I am still unsure on this question. In some cases 128 is much nicer than
16, for example Int128AggState is nicer than Int16AggState and the same
is true for do_int128_accum vs do_int16_accum, but the tricky cases are
things like int16_to_numericvar where there already is a
int8_to_numericvar function and what we should call the functions in
pg_proc (currently named numeric_int16_*).

I also agree with Robert about that we should just pick one estimate and
use that. I picked the smaller one, but that might be too optimistic so
feel free to ask me to switch it back or to pick something in between
the two estimates.

--
Andreas Karlsson

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2015-01-18 01:27:25 proposal: disallow operator "=>" and use it for named parameters
Previous Message Pavel Stehule 2015-01-17 22:43:10 Re: proposal: searching in array function - array_position