Обсуждение: longs where uint64s could be
Folks, 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? Thanks in advance for any insights into this! Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
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
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@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. Please find attached a patch that changes logtape.c and things in near dependency to it that changes longs to appropriate ints. Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate