Re: Use of "long" in incremental sort code

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: Raw Message | Whole Thread | 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

In response to

Browse pgsql-hackers by date

  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