Re: longs where uint64s could be

From: David Fetter <david(at)fetter(dot)org>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: longs where uint64s could be
Date: 2020-01-19 22:45:53
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Fri, Jan 17, 2020 at 05:12:20PM -0800, Peter Geoghegan wrote:
> On Fri, Jan 17, 2020 at 4:42 PM David Fetter <david(at)fetter(dot)org> wrote:
> > While going over places where I might use compiler intrinsics for
> > things like ceil(log2(n))) and next power of 2(n), I noticed that a
> > lot of things that can't be fractional are longs instead of, say,
> > uint64s. Is this the case for historical reasons, or is there some
> > more specific utility to expressing as longs things that can only have
> > non-negative integer values? Did this practice pre-date our
> > now-required 64-bit integers?
> Yeah, it's historic. I wince when I see "long" integers. They're
> almost wrong by definition. Windows has longs that are only 32-bits
> wide/the same width as a regular "int". Anybody that uses a long must
> have done so because they expect it to be wider than an int, even
> though in general it cannot be assumed to be in Postgres C code.
> work_mem calculations often use long by convention. We restrict the
> size of work_mem on Windows in order to make this safe everywhere. I
> believe that this is based on a tacit assumption that long is wider
> outside of Windows.
> logtape.c uses long ints. This means that Windows cannot support very
> large external sorts. I don't recall hearing any complaints about
> that, but it still doesn't seem great.

Please find attached a patch that changes logtape.c and things in near
dependency to it that changes longs to appropriate ints.

David Fetter <david(at)fetter(dot)org>
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres:

Attachment Content-Type Size
v1-0001-Change-the-tape-system-from-long-to-u-int64.patch text/x-diff 14.6 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ranier Vilela 2020-01-19 23:11:56 [PATCH] src\backend\utils\adt\numeric.c copy and past error
Previous Message Dent John 2020-01-19 22:30:33 Re: [WIP] UNNEST(REFCURSOR): allowing SELECT to consume data from a REFCURSOR