Re: Removing "long int"-related limit on hash table sizes
От | Michael Paquier |
---|---|
Тема | Re: Removing "long int"-related limit on hash table sizes |
Дата | |
Msg-id | YP4gMZL9dcDL7Z49@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Removing "long int"-related limit on hash table sizes (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Removing "long int"-related limit on hash table sizes
|
Список | pgsql-hackers |
On Sun, Jul 25, 2021 at 12:28:04PM -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: >> We really ought to just remove every single use of long. > > I have no objection to that as a long-term goal. But I'm not volunteering > to do all the work, and in any case it wouldn't be a back-patchable fix. > I feel that we do need to do something about this performance regression > in v13. Another idea may be to be more aggressive in c.h? A tweak there would be dirtier than marking long as deprecated, but that would be less invasive. Any of that is not backpatchable, of course.. > No, I don't like that. Using size_t for memory-size variables is good > discipline. Moreover, I'm not convinced that even with 64-bit ints, > overflow would be impossible in all the places I fixed here. They're > multiplying several potentially very large values (one of which > is a float). I think this is just plain sloppy coding, independently > of which bit-width you choose to be sloppy in. Yeah, using size_t where adapted is usually a good idea. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: