Re: longs where uint64s could be
От | Peter Geoghegan |
---|---|
Тема | Re: longs where uint64s could be |
Дата | |
Msg-id | CAH2-Wz=FiZT5GDm-y2NngNs_7K-8pSxe8vS3BAW3QEQWREASBQ@mail.gmail.com обсуждение исходный текст |
Ответ на | longs where uint64s could be (David Fetter <david@fetter.org>) |
Ответы |
Re: longs where uint64s could be
|
Список | pgsql-hackers |
On Fri, Jan 17, 2020 at 4:42 PM David Fetter <david@fetter.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
В списке pgsql-hackers по дате отправления: