Re: BUG #18247: Integer overflow leads to negative width
Richard Guo <guofenglinux@gmail.com>
From: Richard Guo <guofenglinux@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Junwang Zhao <zhjwpku@gmail.com>, rekgrpth@gmail.com,
pgsql-bugs@lists.postgresql.org
Date: 2023-12-20T02:05:06Z
Lists: pgsql-bugs
On Tue, Dec 19, 2023 at 11:22 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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. Fair point. > I'll make that change and push it. Thanks for the change and pushing! > 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. Agreed. Thanks Richard
Commits
-
Prevent integer overflow when forming tuple width estimates.
- 7e1ce2b3de16 17.0 landed
-
compute_bitmap_pages' loop_count parameter should be double not int.
- 8b965c549dc8 17.0 landed