Re: Use of "long" in incremental sort code

Поиск
Список
Период
Сортировка
От James Coleman
Тема Re: Use of "long" in incremental sort code
Дата
Msg-id CAAaqYe_Y5zwCTFCJeso7p34yJgf4khR8EaKeJtGd=QPudOad6A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Use of "long" in incremental sort code  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Use of "long" in incremental sort code  (Peter Geoghegan <pg@bowt.ie>)
Re: Use of "long" in incremental sort code  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Use of "long" in incremental sort code  (David Rowley <dgrowleyml@gmail.com>)
Список pgsql-hackers
On Thu, Jul 2, 2020 at 3:39 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Peter Geoghegan <pg@bowt.ie> writes:
> > On Thu, Jul 2, 2020 at 10:53 AM James Coleman <jtc331@gmail.com> wrote:
> >> Do you think it's reasonable to use int64 across the board for memory
> >> and disk space numbers then? If so, I can update the patch.
>
> > Using int64 as a replacement for long is the safest general strategy,
>
> mumble ssize_t mumble

But wouldn't that mean we'd get int on 32-bit systems, and since we're
accumulating data we could go over that value in both memory and disk?

My assumption is that it's preferable to have the "this run value" and
the "total used across multiple runs" and both of those for disk and
memory to be the same. In that case it seems we want to guarantee
64-bits.

Patch using int64 attached.

James

Вложения

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Use of "long" in incremental sort code
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Use of "long" in incremental sort code