From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | James Coleman <jtc331(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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:55:02 |
Message-ID: | CAH2-Wzm8hUwWGb9ojgaMCY4HyzggjdTMcoiQyT2c3Z5mPjQT_g@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 2, 2020 at 12:47 PM James Coleman <jtc331(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-07-02 19:55:31 | Re: Use of "long" in incremental sort code |
Previous Message | Peter Geoghegan | 2020-07-02 19:49:48 | Re: Use of "long" in incremental sort code |