Re: Use of "long" in incremental sort code

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Use of "long" in incremental sort code
Дата
Msg-id 864757.1593719731@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Use of "long" in incremental sort code  (James Coleman <jtc331@gmail.com>)
Список pgsql-hackers
James Coleman <jtc331@gmail.com> writes:
> On Thu, Jul 2, 2020 at 3:39 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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?

Certainly, a number that's meant to represent the amount of data *on disk*
shouldn't use ssize_t.  But I think it's appropriate if you want to
represent in-memory quantities while also allowing negative values.

I guess if you're expecting in-memory sizes exceeding 2GB, you might worry
that ssize_t could overflow.  I'm dubious that a 32-bit machine could get
to that, though, seeing that it's going to have other demands on its
address space.

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

If you're not going to distinguish in-memory from not-in-memory, agreed.

            regards, tom lane



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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Use of "long" in incremental sort code
Следующее
От: Jaka Jančar
Дата:
Сообщение: Re: Sync vs Flush