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
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 |