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

Поиск
Список
Период
Сортировка
От Andreas Karlsson
Тема Re: Using 128-bit integers for sum, avg and statistics aggregates
Дата
Msg-id 54BB0037.5040207@proxel.se
обсуждение исходный текст
Ответ на Re: Using 128-bit integers for sum, avg and statistics aggregates  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: Using 128-bit integers for sum, avg and statistics aggregates  (Andreas Karlsson <andreas@proxel.se>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: proposal: searching in array function - array_position
Следующее
От: Pavel Stehule
Дата:
Сообщение: proposal: disallow operator "=>" and use it for named parameters