Re: optimizer cost calculation problem
От | Tom Lane |
---|---|
Тема | Re: optimizer cost calculation problem |
Дата | |
Msg-id | 1349.1049214241@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: optimizer cost calculation problem ("scott.marlowe" <scott.marlowe@ihs.com>) |
Ответы |
Re: optimizer cost calculation problem
|
Список | pgsql-hackers |
"scott.marlowe" <scott.marlowe@ihs.com> writes: > This isn't really an issue for 64 bit hardware is it? Is "int" 64 bits on such a machine? The ones I've dealt with chose to set int = 32bits, long = 64bits. If they don't do that then they have a problem with not having any native C 32bit type (and promoting short int up to 32 bits just moves the problem...) At some point we should probably try to regularize the backend code so that all memory-size-related calcs are consistently done in size_t or ssize_t arithmetic; but we're a long way from that at present. For now I think it's prudent to keep sort_mem small enough to avoid overflow in int32 arithmetic. regards, tom lane
В списке pgsql-hackers по дате отправления: