From: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
---|---|
To: | mark(at)mark(dot)mielke(dot)cc |
Cc: | Douglas McNaught <doug(at)mcnaught(dot)org>, Naz Gassiep <naz(at)mira(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PostgreSQL on 64 bit Linux |
Date: | 2006-08-21 13:43:20 |
Message-ID: | 44E9B878.3070509@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
mark(at)mark(dot)mielke(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2006-08-21 13:57:21 | Re: snapshot replication with pg_dump |
Previous Message | Martijn van Oosterhout | 2006-08-21 13:41:19 | Re: PostgreSQL on 64 bit Linux |