From: | James Coleman <jtc331(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, David Rowley <dgrowleyml(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Use of "long" in incremental sort code |
Date: | 2020-07-02 19:47:46 |
Message-ID: | CAAaqYe_Y5zwCTFCJeso7p34yJgf4khR8EaKeJtGd=QPudOad6A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 2, 2020 at 3:39 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> > On Thu, Jul 2, 2020 at 10:53 AM James Coleman <jtc331(at)gmail(dot)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 | Content-Type | Size |
---|---|---|
v2-0001-Use-int64-instead-of-long-for-space-used-variable.patch | application/octet-stream | 4.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2020-07-02 19:49:48 | Re: Use of "long" in incremental sort code |
Previous Message | Tom Lane | 2020-07-02 19:44:23 | Re: Use of "long" in incremental sort code |