mark@mark.mielke.cc wrote:
> This is what I mean by after thought. PostgreSQL is designed for
> 32-bit processors. Which is fine. I'm not complaining. The question
> was whether there is an interest in pursuing 64-bit specific
> optimizations. In the PostgreSQL code, a quick check points me only to
> "has long int 64" as a 64-bit source code #ifdef. Of the six places
> that reference this, five of them actually slow down the code, as they
> check for overflow of the 'long int' result beyond 4 bytes of
> data. The sixth place is used to define the 64-bit type in use by
> PostgreSQL, which I suspect is infrequently used.
>
> I believe the answer is no. No or few 64-bit optimization possibilities
> have been chased down, probably because some or many of these would:
>
> 1) require significant re-architecture
>
> 2) reduce the performance in a 32-bit world
Just out of intereset - what areas in postgres do you think could be
improved (performance wise) on 64-bit machines? The only area that
I can see is the int64 datatype - it's stored in palloc()'ed memory
on 32-bit machines AFAIK - I'm not sure if it uses the "long long"
datatype on 64-bit archs.. But I can't imagine any other area that
could be tuned by making use of (native) 64-bit ints.
greetings, Florian Pflug
