Re: "long" type is not appropriate for counting tuples

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: "long" type is not appropriate for counting tuples
Дата
Msg-id aad79a02-8ce4-d963-e660-a84eb7c77c2b@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: "long" type is not appropriate for counting tuples  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: "long" type is not appropriate for counting tuples  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: "long" type is not appropriate for counting tuples  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 2019-05-23 15:52, Robert Haas wrote:
> On Thu, May 23, 2019 at 5:31 AM Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> wrote:
>> Another option is that in cases where it doesn't affect storage layouts,
>> like the counting tuples case that started this thread, code could just
>> use long long int directly instead of int64.  Then if someone wants to
>> make it 128 bits or 96 bits or whatever it would not be a problem.
> 
> I think that sort of thing tends not to work out well, because at some
> point it's likely to be sent out via the wire protocol; at that point
> we'll need a value of a certain width.  Better to use that width right
> from the beginning.

Hmm, by that argument, we shouldn't ever use any integer type other than
int16, int32, and int64.

I'm thinking for example that pgbench makes a lot of use of int64 and
printing that out makes quite messy code.  Replacing that by long long
int would make this much nicer and should be pretty harmless relative to
your concern.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



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

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" testpending solution of its timing is (fwd)
Следующее
От: Binguo Bao
Дата:
Сообщение: Re: pglz performance