Re: optimizer cost calculation problem - Mailing list pgsql-hackers

From Tom Lane
Subject Re: optimizer cost calculation problem
Date
Msg-id 1349.1049214241@sss.pgh.pa.us
Whole thread Raw
In response to Re: optimizer cost calculation problem  ("scott.marlowe" <scott.marlowe@ihs.com>)
Responses Re: optimizer cost calculation problem  (Andrew Sullivan <andrew@libertyrms.info>)
List 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 by date:

Previous
From: "scott.marlowe"
Date:
Subject: Re: optimizer cost calculation problem
Next
From: "Zeugswetter Andreas SB SD"
Date:
Subject: Re: Nested transactions: low level stuff