Re: Use of "long" in incremental sort code
James Coleman <jtc331@gmail.com>
From: James Coleman <jtc331@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Geoghegan <pg@bowt.ie>, David Rowley <dgrowleyml@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2020-07-02T19:47:46Z
Lists: pgsql-hackers
Attachments
- v2-0001-Use-int64-instead-of-long-for-space-used-variable.patch (application/octet-stream) patch v2-0001
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
Commits
-
Use int64 instead of long in incremental sort code
- 6ee3b5fb990e 14.0 landed
- 22c105595fc7 13.0 landed