From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
cc: Junwang Zhao <zhjwpku@gmail.com>, rekgrpth@gmail.com,
        pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18247: Integer overflow leads to negative width
In-reply-to: 
 <CAMbWs4-pYv=UkkdF_47w-a5OSgs5GQaZANib0YJc6mSp531Z5A@mail.gmail.com>
References: <18247-11ac477f02954422@postgresql.org>
 <CAMbWs48nZf9XgAVpXbOnwGWWLnmoOZb51wnhkNW5xfz_PyOyCw@mail.gmail.com>
 <2781181.1702565025@sss.pgh.pa.us>
 <CAMbWs4_8+mtt5C8EXmfHa_Hs-OW6EhEz_XjhzBk8miwg2h65CQ@mail.gmail.com>
 <2993260.1702654983@sss.pgh.pa.us>
 <CAMbWs49A6rMO6WD1ECvZUKXuzMxBDyXP6CmJKQoCS5=w-tjL7w@mail.gmail.com>
 <CAEG8a3+=_hWJgGVzWBNrOQtuSsYFOzu4esnQ=G+XfqAeRykQKw@mail.gmail.com>
 <4099430.1702933230@sss.pgh.pa.us>
 <CAMbWs48NGPnJiqkRZx7RCYhyjK_JP0qkxVVjrD84FDYZbD4yqw@mail.gmail.com>
 <4150261.1702958937@sss.pgh.pa.us>
 <CAMbWs4-pYv=UkkdF_47w-a5OSgs5GQaZANib0YJc6mSp531Z5A@mail.gmail.com>
Comments: In-reply-to Richard Guo <guofenglinux@gmail.com>
	message dated "Tue, 19 Dec 2023 13:53:59 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <36776.1702999340.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Tue, 19 Dec 2023 10:22:20 -0500
Message-ID: <36777.1702999340@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/36777.1702999340%40sss.pgh.pa.us>
Precedence: bulk

Richard Guo <guofenglinux@gmail.com> writes:
> On Tue, Dec 19, 2023 at 12:08 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Thanks for looking!  Do you have an opinion about the int64-vs-double
>> question?

> To be honest, I don't have a preference on which one is better.  I think
> double is good enough for now as we don't need to worry about overflow
> with it.

After sleeping on it, I'm coming around to the idea that int64 will
be better.  The argument that convinces me is that using int64
provides a datatype-based clue that we are working with a width
and not a row count, cost, or selectivity number.  I don't feel
a need to go as far as invent a typedef alias like Cardinality;
but plain "double" in the planner tends to be a rowcount estimate,
which is not what we want people to think of.

I'll make that change and push it.

BTW, I think it's sufficient to fix this in HEAD.  The troublesome
example seems quite artificial to me, and we've not heard field
reports suggesting that people have had real problems here.

			regards, tom lane