Re: Use of "long" in incremental sort code
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: James Coleman <jtc331@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, David Rowley <dgrowleyml@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2020-07-02T19:55:02Z
Lists: pgsql-hackers
On Thu, Jul 2, 2020 at 12:47 PM James Coleman <jtc331@gmail.com> wrote: > 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. I agree. There seems to be little reason to accommodate platform level conventions, beyond making sure that everything works on less popular or obsolete platforms. I suppose that it's a little idiosyncratic to use int64 like this. But it makes sense, and isn't nearly as ugly as the long thing, so I don't think that it should really matter. -- Peter Geoghegan
Commits
-
Use int64 instead of long in incremental sort code
- 6ee3b5fb990e 14.0 landed
- 22c105595fc7 13.0 landed