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

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Using 128-bit integers for sum, avg and statistics aggregates
Дата
Msg-id CAM3SWZQ1jAZ9tSfMfN3qcT6eT58cOHYPPEVnS7x+rN1wnG5nFA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Using 128-bit integers for sum, avg and statistics aggregates  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: Using 128-bit integers for sum, avg and statistics aggregates  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
On Wed, Mar 18, 2015 at 1:05 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> I think it's a pretty direct copy of the 64bit code. I'm not entirely
> sure why this needs a AC_TRY_RUN with a compile fallback (for cross) and
> why a AC_TRY_LINK isn't sufficient? But then, you just copied that
> decision.

Good point.

Anyway, I think that it's not quite the same. For one thing, we're
talking about a GCC extension, not a type described by C99. We don't
care about snprintf support, for example. For another, Andreas has
chosen to lump together __int128 and unsigned __int128 into one test,
where the latter really doesn't receive coverage. This only makes
sense from the point of view of this optimization, since we need both
anyway, as int128_to_numericvar() uses the uint128 type. I think it's
fine to only use int128/uint128 for this optimization, and similar
optimizations, and consequently I think it's fine to lump the two
types together, but lets be clear that that's all we mean to do.

I'm going to keep things that way, and try and test unsigned __int128
too (but as part of the same, single configure test). It's not merely
a matter of mechanically copying what we do for int64 (or uint64),
though.

-- 
Peter Geoghegan



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

Предыдущее
От: hitesh ramani
Дата:
Сообщение: GSoC - Idea Discussion
Следующее
От: Andres Freund
Дата:
Сообщение: Re: parallel mode and parallel contexts