From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: longs where uint64s could be |
Date: | 2020-01-18 01:12:20 |
Message-ID: | CAH2-Wz=FiZT5GDm-y2NngNs_7K-8pSxe8vS3BAW3QEQWREASBQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2020-01-18 01:43:04 | Re: Amcheck: do rightlink verification with lock coupling |
Previous Message | David Fetter | 2020-01-18 00:42:14 | longs where uint64s could be |