Re: Use of "long" in incremental sort code - Mailing list pgsql-hackers

From James Coleman
Subject Re: Use of "long" in incremental sort code
Date
Msg-id CAAaqYe_Y5zwCTFCJeso7p34yJgf4khR8EaKeJtGd=QPudOad6A@mail.gmail.com
Whole thread Raw
In response to Re: Use of "long" in incremental sort code  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses 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>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Use of "long" in incremental sort code
Next
From: Peter Geoghegan
Date:
Subject: Re: Use of "long" in incremental sort code