Re: "long" type is not appropriate for counting tuples

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: "long" type is not appropriate for counting tuples
Date: 2019-04-29 18:18:49
Message-ID: CAH2-Wzk2+4jdf8FC9Qj+2k_52G6EPAwu0yUFMCuPfuMSKppwXA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 29, 2019 at 11:10 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> If we don't want to rely on "L" constants then we'll have to write these
> cases like "work_mem * (size_t) 1024" which is ugly, lots more keystrokes,
> and prone to weird precedence problems unless you throw even more
> keystrokes (parentheses) at it. I'm not excited about doing that just
> to allow larger work_mem settings on Win64.

I don't think that anybody cares about Win64 very much. Simplifying
the code might lead to larger work_mem settings on that platform, but
that's not the end goal I have in mind. For me, the end goal is
simpler code.

> I'm not suggesting that we don't need to fix uses of "long" for tuple
> counts, and perhaps other things. But I think getting rid of it in memory
> size calculations might be a lot of work for not a lot of reward.

Whether or not *fully* banning the use of "long" is something that
will simplify the code is debatable. However, we could substantially
reduce the use of "long" across the backend without any real downside.
The work_mem question can be considered later. Does that seem
reasonable?

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-04-29 18:19:19 Re: "long" type is not appropriate for counting tuples
Previous Message Tom Lane 2019-04-29 18:10:24 Re: "long" type is not appropriate for counting tuples