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 по дате отправления: