Re: [HACKERS] PostgreSQL on 64 bit Linux
On 21 Aug 2006, at 10:48, [EMAIL PROTECTED] wrote: On Mon, Aug 21, 2006 at 12:00:58PM +0300, Alexander Kirpa wrote: WRT 64-bit and Postgres, it depends on the CPU as to whether you see a simple performance benefit. On the Opteron you will see a benefit when doing CPU bound work. When doing the CPU portion, the additional registers of the Opteron running in 64-bit mode are used by the compiler to produce a 20-30% boost in performance. On the Xeon in 64-bit mode, the same regions of execution will slow down by about 5%. Postgres benefits automatically from the larger memory addressing of the 64-bit kernel by using the larger I/O cache of Linux. Main benefit Postgres in 64-bit mode possible only in case dedicated DB server on system with RAM 3GB and use most part of RAM for shared buffers and avoid persistent moving buffers between OS cache and shared memory. On system with RAM below 2-3GB to difficult found serious gain of performance. This is the main difference between PostgreSQL today - designed for 32-bit - when recompiled with a 64-bit compiler. The additional registers are barely enough to counter the increased cost of processing in 64-bits. Cheers, mark Current 32-bit Postgres architecture allow use main benefit of 64-bit OS - huge memory size for shared buffers. At current time possible use 2G x 8KB = 16TB as shared memory and regarding this issue need use (O_DIRECT) to avoid OS cache especially in case databases fit to shared memory. Best regards, Alexander Kirpa ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] PostgreSQL on 64 bit Linux
On Mon, Aug 21, 2006 at 02:56:10PM +1200, Andrej Ricnik-Bay wrote: On 8/21/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Is there an interest, or any active project to examine PostgreSQL in the area of 64-bit processors? Has it already been done? I don't recall seeing a reference to it in my travels. I'm also not sure on what to expect for results, as the territory is still new. 64-bit processors have existed for a while, but 32-bit processors have been the popular choice, making 64-bit support an after thought? That's certainly just a reference to the wintel world? AIX, HP-UX and Solaris-Sparc have been 64-bit for a while now... I don't think so. In the Open Source world, most projects are still 32-bit centric, regardless of how many years the products have been supported on 64-bit platforms. What application were you thinking of that takes full advantage of 64-bit, making the 64-bit application much significantly faster than the 32-bit application? The only area I am aware of, is video processing. It's often a surprise to people that an upgrade to 64-bit, regardless of CPU architecture, too often ends up slower, rather than faster. Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL on 64 bit Linux
On Sun, Aug 20, 2006 at 11:00:26PM -0400, Douglas McNaught wrote: [EMAIL PROTECTED] writes: Is there an interest, or any active project to examine PostgreSQL in the area of 64-bit processors? Has it already been done? I don't recall seeing a reference to it in my travels. I'm also not sure on what to expect for results, as the territory is still new. 64-bit processors have existed for a while, but 32-bit processors have been the popular choice, making 64-bit support an after thought? I find this question a bit amusing, since PG has run on 64-bit architectures such as MIPS, Sparc, Alpha and PA-RISC for quite a while now. :) I don't think so. Software can be designed to take best advantage of hardware. Recompiling it for a different architecture, running test cases, and declaring support, is not the same as optimizing for. As I said in a private email to Naz, the main advantage I think you'd see from 64-bit is the ability to run with more than 2GB or so of shared buffers on a system with lots of RAM. Whether you'd want to do that, or let the OS do most of the buffering, is an open question... 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 It's a question that only half interests me. As with most projects, I don't think the projects are ready to re-architect for this purpose. Perhaps once 50%+ of people are running PostgreSQL in 64-bit mode, the question will be more serious to more people. As a half interesting question, I'm defending it as a valid question. Please don't write it off, but it is fine to say not yet, we have more important things to work on. Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] PostgreSQL on 64 bit Linux
[EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] PostgreSQL on 64 bit Linux
On Mon, Aug 21, 2006 at 09:16:46AM -0400, [EMAIL PROTECTED] 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. There are two defines, the end result being to declare an int64 type which is used a fair bit around the place. biginteger and bigserial being the obvious ones. The checks I see relate to strtol, where the code only wants an int4. There's no strtoi so on 32 bit the range check is built-in, but if long is 64 bit you have to do the check seperatly. That's just an interface problem, there's not a lot we can do about that really. 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 Can you think of any places at all where 64-bit would make a difference to processing? 64-bit gives you more memory, and on some x86 chips, more registers, but that's it. Have anice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] PostgreSQL on 64 bit Linux
Martijn van Oosterhout kleptog@svana.org writes: Can you think of any places at all where 64-bit would make a difference to processing? 64-bit gives you more memory, and on some x86 chips, more registers, but that's it. It would be interesting to look into making int8 and float8 be pass-by-value datatypes to save palloc overhead on machines where Datum is going to be 8 bytes wide anyway. Of course this would only help queries that use those datatypes extensively, and it might be an insignificant savings anyhow :-( For the most part though I think that the main advantage of 64-bit for a database is the ability to address more memory. We've been working slowly towards allowing PG to make better use of large numbers of shared buffers, for instance. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PostgreSQL on 64 bit Linux
[EMAIL PROTECTED] writes: 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 Honestly, I think the main optimizations happen automatically: the compiler uses the extra registers (if present) and pointers in LP64 mode are automatically 64-bit, which allows much larger memory areas. That's probably 95% of the win right there. What other optimizations need doing? People have been running PG with big databases on 64-bit iron for years; don't you think any glaring infelicities would have been addressed? It's a question that only half interests me. As with most projects, I don't think the projects are ready to re-architect for this purpose. What re-architecting would be needed? -Doug ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] PostgreSQL on 64 bit Linux
WRT 64-bit and Postgres, it depends on the CPU as to whether you see a simple performance benefit. On the Opteron you will see a benefit when doing CPU bound work. When doing the CPU portion, the additional registers of the Opteron running in 64-bit mode are used by the compiler to produce a 20-30% boost in performance. On the Xeon in 64-bit mode, the same regions of execution will slow down by about 5%. Postgres benefits automatically from the larger memory addressing of the 64-bit kernel by using the larger I/O cache of Linux. Main benefit Postgres in 64-bit mode possible only in case dedicated DB server on system with RAM 3GB and use most part of RAM for shared buffers and avoid persistent moving buffers between OS cache and shared memory. On system with RAM below 2-3GB to difficult found serious gain of performance. Best regards, Alexander Kirpa ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] PostgreSQL on 64 bit Linux
On Mon, Aug 21, 2006 at 10:23:16AM -0400, Douglas McNaught wrote: [EMAIL PROTECTED] writes: 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 Honestly, I think the main optimizations happen automatically: the compiler uses the extra registers (if present) and pointers in LP64 mode are automatically 64-bit, which allows much larger memory areas. That's probably 95% of the win right there. What other optimizations need doing? Compilers are getting smarter, but having code profiled, and hand tuned for 32-bits does not automatically get compiled with a 64-bit compiler, to code that has been profile, and hand tuned for 64-bit. An example of this is in how algorithms are implemented. For Intel-style processors at least, using array offsets is cheaper than using many pointers. For 64-bit processors, 32-bit array offsets would use less memory. For re-architecture, the first thing that came to mind was Datum increasing in size. Copy by value instead of allocating a pointer, and passing the pointer. The pointer will be 64-bits, so Datum could support 64-bits as well. Tom caught this, but he did point out what I missed. This would only benefit data types that are 64-bits in length, which are still likely uncommon (most people would use serial, not bigserial). Has anybody taken any of the 64-bit processor optimization manuals, and walked through it, cross referencing it against bottleneck programs in PostgreSQL? To counter this, I suggest to you that most every attempt to optimize PostgreSQL for performance reasons, likely considered variations in algorithms measured on a 32-bit processor, finally selecting the version that was simplest, and best performing, on a 32-bit processor. This is normal evolution for a piece of software. It is naturally optimized for the processor that is most used by the users. I'm not the expert on the matter. I don't see evidence that anybody has taken this route though. People have been running PG with big databases on 64-bit iron for years; don't you think any glaring infelicities would have been addressed? I doubt there are 'glaring infelicities'. I doubt any changes required to provide a noticeable speed improvement would be one liners. They will not be obvious. They will require a complete understanding of the many architectural differences between common 32-bit processors, and common 64-bit processors. Few have this information in their head. I don't. I suspect that anybody who claims that the only difference is the amount of addressable memory, and the number of registers doesn't. :-) It's a question that only half interests me. As with most projects, I don't think the projects are ready to re-architect for this purpose. What re-architecting would be needed? I'm asking that it be admitted that it has not been looked at. Not seriously. Nor is this unique to PostgreSQL. I expect the performance for Linux applications in general to slowly improve on 64-bit processors as more and more people begin to use it. I recall a few threads on other mailing lists where the primary developers admitted to not having ready access to a 64-bit machine. Until they do, the chance that these applications are hand-tuned for 64-bit is unlikely. I'm not claiming that I have the answers. I am claiming that a few of you share this weakness, and that an assumption that PostgreSQL is designed for 64-bit would be incorrect. :-) Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] PostgreSQL on 64 bit Linux
On Mon, Aug 21, 2006 at 12:00:58PM +0300, Alexander Kirpa wrote: WRT 64-bit and Postgres, it depends on the CPU as to whether you see a simple performance benefit. On the Opteron you will see a benefit when doing CPU bound work. When doing the CPU portion, the additional registers of the Opteron running in 64-bit mode are used by the compiler to produce a 20-30% boost in performance. On the Xeon in 64-bit mode, the same regions of execution will slow down by about 5%. Postgres benefits automatically from the larger memory addressing of the 64-bit kernel by using the larger I/O cache of Linux. Main benefit Postgres in 64-bit mode possible only in case dedicated DB server on system with RAM 3GB and use most part of RAM for shared buffers and avoid persistent moving buffers between OS cache and shared memory. On system with RAM below 2-3GB to difficult found serious gain of performance. This is the main difference between PostgreSQL today - designed for 32-bit - when recompiled with a 64-bit compiler. The additional registers are barely enough to counter the increased cost of processing in 64-bits. Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] PostgreSQL on 64 bit Linux
On Mon, Aug 21, 2006 at 10:46:56AM -0400, [EMAIL PROTECTED] wrote: Compilers are getting smarter, but having code profiled, and hand tuned for 32-bits does not automatically get compiled with a 64-bit compiler, to code that has been profile, and hand tuned for 64-bit. I don't see any evidence that anyone has any kind of hand-tuning, not for 32-bit, not for 64-bit. That's compiler's job really. That's said, if you want to go hand-tuning, go for the low-hanging fruit first: using likely()/unlikely() in often used code paths (heap_get_attr for example), find the parts of the code that could benefit from strict-aliasing, etc. In general we avoid architechture specific code because the cost of maintainence outweighs the benefits. For re-architecture, the first thing that came to mind was Datum increasing in size. Copy by value instead of allocating a pointer, and passing the pointer. The pointer will be 64-bits, so Datum could support 64-bits as well. Tom caught this, but he did point out what I missed. This would only benefit data types that are 64-bits in length, which are still likely uncommon (most people would use serial, not bigserial). A Datum must be 64-bit on a 64-bit arch, how else is it going to hold the pointer for a pass-by-ref value? On the whole, PostgreSQL is still in the phase where we're trying to find the best algorithms. When that's done (if ever), we can start worrying about processor optimisations... Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] PostgreSQL on 64 bit Linux
On Mon, Aug 21, 2006 at 05:13:58PM +0200, Martijn van Oosterhout wrote: On the whole, PostgreSQL is still in the phase where we're trying to find the best algorithms. When that's done (if ever), we can start worrying about processor optimisations... I don't disagree. :-) You claimed that PostgreSQL is not tuned to a specific processor, and relies on the kernel, the compiler, and libc to perform some tuning. I agree with this as well. Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] PostgreSQL on 64 bit Linux
[EMAIL PROTECTED] writes: What re-architecting would be needed? I'm asking that it be admitted that it has not been looked at. Not seriously. Nor is this unique to PostgreSQL. I expect the performance for Linux applications in general to slowly improve on 64-bit processors as more and more people begin to use it. I recall a few threads on other mailing lists where the primary developers admitted to not having ready access to a 64-bit machine. Until they do, the chance that these applications are hand-tuned for 64-bit is unlikely. What you seem to be asking for is that we engage in a lot of machine-specific tuning for some particular processor or other. That has not happened and will not happen. This project believes in portable code, not optimized for Xeon-of-the-month code. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] PostgreSQL on 64 bit Linux
On Mon, Aug 21, 2006 at 01:05:13PM -0400, Tom Lane wrote: [EMAIL PROTECTED] writes: What re-architecting would be needed? I'm asking that it be admitted that it has not been looked at. Not seriously. Nor is this unique to PostgreSQL. I expect the performance for Linux applications in general to slowly improve on 64-bit processors as more and more people begin to use it. I recall a few threads on other mailing lists where the primary developers admitted to not having ready access to a 64-bit machine. Until they do, the chance that these applications are hand-tuned for 64-bit is unlikely. What you seem to be asking for is that we engage in a lot of machine-specific tuning for some particular processor or other. That has not happened and will not happen. This project believes in portable code, not optimized for Xeon-of-the-month code. Hi Tom. I'm asking for a statement such as the above, that you provide. :-) The question was whether PostgreSQL was optimized for 64-bit Linux. The answer is not specifically. The answer is quite acceptable to me. It's not the original answer that was given to the original poster though... :-) Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL on 64 bit Linux
[EMAIL PROTECTED] writes: On Mon, Aug 21, 2006 at 01:05:13PM -0400, Tom Lane wrote: What you seem to be asking for is that we engage in a lot of machine-specific tuning for some particular processor or other. The question was whether PostgreSQL was optimized for 64-bit Linux. The answer is not specifically. Well, my notion of optimizing for 64 bit seems to have little to do with yours. To me, stuff like making sure we can use lots of buffers effectively is a 64-bit optimization. What you seem to have in mind is assembly-code-level optimization for specific processors. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] PostgreSQL on 64 bit Linux
Naz Gassiep [EMAIL PROTECTED] writes: I have a PostgreSQL installation on a Debian box that had the 64bit SMP kernel installed before PostgreSQL was compiled and installed on it. Does PostgreSQL take any advantage of the 64 bit environment or have we not done anything to move into the 64 bit world yet? Depends on whether PG was compiled as 64-bit or 32-bit--is your toolchain 64-bit all the way, or is it just the kernel? -Doug ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL on 64 bit Linux
Douglas McNaught wrote: Naz Gassiep [EMAIL PROTECTED] writes: I have a PostgreSQL installation on a Debian box that had the 64bit SMP kernel installed before PostgreSQL was compiled and installed on it. Does PostgreSQL take any advantage of the 64 bit environment or have we not done anything to move into the 64 bit world yet? Depends on whether PG was compiled as 64-bit or 32-bit--is your toolchain 64-bit all the way, or is it just the kernel? -Doug I just compiled as the manual says. I guess I must have compiled it in 32. I'll recompile in 64 when I upgrade to 8.2 when it's out. Thanks, - Naz.
Re: [HACKERS] PostgreSQL on 64 bit Linux
Naz Gassiep [EMAIL PROTECTED] writes: I just compiled as the manual says. I guess I must have compiled it in 32. I'll recompile in 64 when I upgrade to 8.2 when it's out. The 'file' command will tell you whether a binary is 32- or 64-bit. If you have a full 64-bit install, you'll get a 64-bit compile by default, but it sounds like you just added a 64-bit kernel to a 32-bit Debian system? -Doug ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL on 64 bit Linux
On Sun, Aug 20, 2006 at 04:46:30PM -0400, Douglas McNaught wrote: Naz Gassiep [EMAIL PROTECTED] writes: I have a PostgreSQL installation on a Debian box that had the 64bit SMP kernel installed before PostgreSQL was compiled and installed on it. Does PostgreSQL take any advantage of the 64 bit environment or have we not done anything to move into the 64 bit world yet? Depends on whether PG was compiled as 64-bit or 32-bit--is your toolchain 64-bit all the way, or is it just the kernel? I think he means - have benchmarks, or profiling been done with the goal of specifically improving performance on 64-bit platforms. For most applications available today, the answer is no. Compiling an application designed for 32-bit, on a 64-bit architecture, does not automatically improve performance. Too frequently, it can actually reduce performance. Pointers are large, which means that any application that is heavily pointer based can be forced to deal with twice as many copies of memory, which reduces the effectiveness of the various cache levels, and RAM itself. Hopefully GLIBC counts here, in that it should contain 64-bit specific code where it might count, so libc calls should be able to take advantage of the 64-bit machine instructions. Is there an interest, or any active project to examine PostgreSQL in the area of 64-bit processors? Has it already been done? I don't recall seeing a reference to it in my travels. I'm also not sure on what to expect for results, as the territory is still new. 64-bit processors have existed for a while, but 32-bit processors have been the popular choice, making 64-bit support an after thought? Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] PostgreSQL on 64 bit Linux
On 8/21/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Is there an interest, or any active project to examine PostgreSQL in the area of 64-bit processors? Has it already been done? I don't recall seeing a reference to it in my travels. I'm also not sure on what to expect for results, as the territory is still new. 64-bit processors have existed for a while, but 32-bit processors have been the popular choice, making 64-bit support an after thought? That's certainly just a reference to the wintel world? AIX, HP-UX and Solaris-Sparc have been 64-bit for a while now... Cheers, mark Cheers, Andrej -- Please don't top post, and don't use HTML e-Mail :} Make your quotes concise. http://www.american.edu/econ/notes/htmlmail.htm ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PostgreSQL on 64 bit Linux
[EMAIL PROTECTED] writes: Is there an interest, or any active project to examine PostgreSQL in the area of 64-bit processors? Has it already been done? I don't recall seeing a reference to it in my travels. I'm also not sure on what to expect for results, as the territory is still new. 64-bit processors have existed for a while, but 32-bit processors have been the popular choice, making 64-bit support an after thought? I find this question a bit amusing, since PG has run on 64-bit architectures such as MIPS, Sparc, Alpha and PA-RISC for quite a while now. :) As I said in a private email to Naz, the main advantage I think you'd see from 64-bit is the ability to run with more than 2GB or so of shared buffers on a system with lots of RAM. Whether you'd want to do that, or let the OS do most of the buffering, is an open question... -Doug ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PostgreSQL on 64 bit Linux
Naz, On 8/20/06 12:59 PM, Naz Gassiep [EMAIL PROTECTED] wrote: I have a PostgreSQL installation on a Debian box that had the 64bit SMP kernel installed before PostgreSQL was compiled and installed on it. Does PostgreSQL take any advantage of the 64 bit environment or have we not done anything to move into the 64 bit world yet? Very likely the default gcc compiles for 64-bit, if not you need to specify -m64. As another respondent said - do a file `which initdb` to find out whether you have compiled for 64-bit or not. WRT 64-bit and Postgres, it depends on the CPU as to whether you see a simple performance benefit. On the Opteron you will see a benefit when doing CPU bound work. When doing the CPU portion, the additional registers of the Opteron running in 64-bit mode are used by the compiler to produce a 20-30% boost in performance. On the Xeon in 64-bit mode, the same regions of execution will slow down by about 5%. Postgres benefits automatically from the larger memory addressing of the 64-bit kernel by using the larger I/O cache of Linux. - Luke ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] PostgreSQL on 64 bit Linux
WRT 64-bit and Postgres, it depends on the CPU as to whether you see a simple performance benefit. On the Opteron you will see a benefit when doing CPU bound work. When doing the CPU portion, the additional registers of the Opteron running in 64-bit mode are used by the compiler to produce a 20-30% boost in performance. On the Xeon in 64-bit mode, the same regions of execution will slow down by about 5%. Is that true of even Woodcrest? Joshua D. Drake Postgres benefits automatically from the larger memory addressing of the 64-bit kernel by using the larger I/O cache of Linux. - Luke ---(end of broadcast)--- TIP 6: explain analyze is your friend -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] PostgreSQL on 64 bit Linux
Josh, On 8/20/06 8:52 PM, Joshua D. Drake [EMAIL PROTECTED] wrote: Is that true of even Woodcrest? Joshua D. Drake Not sure - haven't read anything about the register set on the Core 2 to make me think it benefits from 64 bit. The point may be academic from now on though - the comparisons between Opteron and Core 2 will all likely be in 64-bit mode from now on. - Luke ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
