By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,526 Members | 2,189 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,526 IT Pros & Developers. It's quick & easy.

Quad Xeon vs. Dual Itanium

P: n/a
Hi, all.

I need to upgrade my dual Xeon PostgreSQL engine.

Assuming similar memory and disk sub-systems, I am considering a Quad
Xeon system vs. a Dual Itanium for PostgreSQL. I believe that the
PostgreSQL code is written for 32 bit and not optimized for the 64 bit
Itanium cpu. That makes me think that the Xeon system would be a better
choice.

Do any of you have thoughts on:

1. Straight performance capability
2. Price/Performance
I would appreciate any feedback you might have.
....john
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 22 '05 #1
Share this Question
Share on Google+
25 Replies


P: n/a
John Gibson <gi*@edgate.com> writes:
Assuming similar memory and disk sub-systems, I am considering a Quad
Xeon system vs. a Dual Itanium for PostgreSQL. I believe that the
PostgreSQL code is written for 32 bit and not optimized for the 64 bit
Itanium cpu. That makes me think that the Xeon system would be a
better choice.


Postgres runs on many 64-bit systems, including UltraSPARC, MIPS, and
Alpha, plus the Intel and AMD offerings. What makes you think it's
'not optimized'?

-Doug

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 22 '05 #2

P: n/a
Hello list,

I'm designing a plperlu function and i was wondering about scoping on
use statements for external libraries. I couldn't find any information
on it in the documentation or in the mail archives, so any information
would be much appreciated.

The function is intended to be used as part of a select statement:

select foo,my_function(bar) as baz from table where baz > some_value
order by baz

And the function uses an external module to do much of the heavy
lifting. What I'm wondering is will the function have to reload the
external module for every row, or is plperlu smart enough to only load
it once for the entire query? In the other extreme, I'm hoping that it
does reload the external module for each query, as I expect to be
dynamically rewriting one of the modules that that external module requires.

-Stephen
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 22 '05 #3

P: n/a
-----Original Message-----
From: pg*****************@postgresql.org
[mailto:pg*****************@postgresql.org] On Behalf Of Doug McNaught
Sent: Monday, February 09, 2004 10:44 AM
To: John Gibson
Cc: pg***********@postgresql.org
Subject: Re: [GENERAL] Quad Xeon vs. Dual Itanium

John Gibson <gi*@edgate.com> writes:
Assuming similar memory and disk sub-systems, I am considering a Quad
Xeon system vs. a Dual Itanium for PostgreSQL. I believe that the
PostgreSQL code is written for 32 bit and not optimized for the 64 bit
Itanium cpu. That makes me think that the Xeon system would be a
better choice.


Postgres runs on many 64-bit systems, including UltraSPARC, MIPS, and
Alpha, plus the Intel and AMD offerings. What makes you think it's
'not optimized'?

-Doug
-------------------------

The only way I can see that its not optimized for 64 bit would be to use
32bit binaries on it, and the only way that can even happen is on the new
amd chips I believe, or will itanium run 32bit apps also?

Rob
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 22 '05 #4

P: n/a
Clinging to sanity, gi*@edgate.com (John Gibson) mumbled into her beard:
I need to upgrade my dual Xeon PostgreSQL engine.

Assuming similar memory and disk sub-systems, I am considering a
Quad Xeon system vs. a Dual Itanium for PostgreSQL. I believe that
the PostgreSQL code is written for 32 bit and not optimized for the
64 bit Itanium cpu. That makes me think that the Xeon system would
be a better choice.

Do any of you have thoughts on:

1. Straight performance capability
2. Price/Performance


First thing: What, in particular, makes you think that PostgreSQL code
was written to make it slower or otherwise more restrictive on 64 bit
systems than it needs to be?

Lots of people have been running it on 64 bit systems for _years_ now.
The Digital Alpha architecture, for instance, was introduced in the
1992, and Sun UltraSPARC in 1995. PostgreSQL has been running well on
these sorts of systems for a lot of years now.

Your belief of it being "written for 32 bit" should fly away in the
wake of that.

Secondly, there's a significant counterargument to this, on Intel,
when you look at memory availability.

I have been tearing hair out with some FreeBSD testing in that I have
some quad Xeon systems with 8GB of memory, which gives me the dilemma
of choosing between:

a) Ignoring 4GB of it, or
b) Not having disk connected.

The problem is that having large amounts of memory requires invoking
an Intel "hack" (on FreeBSD, the option is called "PAE"), which
happens to break the disk subsystem. (At least for the controller I
have got.)

And irrespective of any "successful hacks," you are still limited to
either 2GB or 4GB of memory for the postmaster.

If you jump into a 64 bit platform, those sorts of hacks evaporate as
unnecessary, and the main process can get as big as you need it to.
--
(format nil "~S@~S" "cbbrowne" "acm.org")
http://www.ntlug.org/~cbbrowne/rdbms.html
``God decided to take the devil to court and settle their differences
once and for all. When Satan heard of this, he grinned and said, "And
just where do you think you're going to find a lawyer?"''
Nov 22 '05 #5

P: n/a
John Gibson wrote:

Assuming similar memory and disk sub-systems, I am considering a Quad
Xeon system vs. a Dual Itanium for PostgreSQL. I believe that the
PostgreSQL code is written for 32 bit and not optimized for the 64 bit
Itanium cpu. That makes me think that the Xeon system would be a better
choice.

The Itanic hasn't lived up to its marketing hype. The comparisons
I've seen between it and a 32-bit CPU show performance differences
primarily due to clock speeds. So far the only advantage of 64 bits is
address space. And because they are new, itanics cost much more.
So with 2 itanics you get a slight improvement. With 4 xeons you get
about 1.7x improvement over your current setup.

--
jimoe at sohnen-moe dot com

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 22 '05 #6

P: n/a
John Gibson wrote:
Hi, all.

I need to upgrade my dual Xeon PostgreSQL engine.

Assuming similar memory and disk sub-systems, I am considering a Quad
Xeon system vs. a Dual Itanium for PostgreSQL. I believe that the
PostgreSQL code is written for 32 bit and not optimized for the 64 bit
Itanium cpu. That makes me think that the Xeon system would be a better
choice.
'
Bang for the buck per CPU you are best off using an Opteron based
solution from AMD. This will give you the 64bit address space that Xeon
can't but for a heck of a lot less money than an Itanium.

Sincerely,

Joshua D. Drake


Do any of you have thoughts on:

1. Straight performance capability
2. Price/Performance
I would appreciate any feedback you might have.
...john
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 22 '05 #7

P: n/a
At 11:44 AM 2/9/2004 -0500, Doug McNaught wrote:
John Gibson <gi*@edgate.com> writes:
Assuming similar memory and disk sub-systems, I am considering a Quad
Xeon system vs. a Dual Itanium for PostgreSQL. I believe that the
PostgreSQL code is written for 32 bit and not optimized for the 64 bit
Itanium cpu. That makes me think that the Xeon system would be a
better choice.


Postgres runs on many 64-bit systems, including UltraSPARC, MIPS, and
Alpha, plus the Intel and AMD offerings. What makes you think it's
'not optimized'?


Maybe compilers aren't as good at doing Itanium yet?

John Gibson <gi*@edgate.com> writes: "I need to upgrade my dual Xeon
PostgreSQL engine."
It just might be helpful if you could tell us "where it hurts".

Unless you need cutting edge floating point performance I doubt you'd want
an Itanium (and even if you do, you might wish to consider powerpc as well).

Without any more info, I'd ask why not dual/quad Opteron? Even if you don't
recompile or wait for better compilers or use 64 bit such a system would
probably run faster than your dual Xeons.
---

http://www.infoworld.com/article/04/...FElinux_2.html

"Tests were run on three separate hardware platforms: Intel Xeon (x86),
Intel Itanium (IA-64), and AMD Opteron (x86_64). The x86 tests were
conducted on an IBM eServer x335 1U rack-mount server with dual 3.06GHz P4
Xeon processors and 2GB of RAM. The Itanium tests were run on an IBM
eServer x450 3U rack-mount server with dual 1.5GHz Itanium2 processors and
2GB of RAM. And the Opteron tests were run on a Newisys 4300 3U rack-mount
server with dual 2.2GHz Opteron 848 processors and 2GB of RAM. "

Summary: Dual Itanium slower than Xeon in many tests, Opteron fastest in
most tests.


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 22 '05 #8

P: n/a
On Mon, 9 Feb 2004, John Gibson wrote:
Hi, all.

I need to upgrade my dual Xeon PostgreSQL engine.

Assuming similar memory and disk sub-systems, I am considering a Quad
Xeon system vs. a Dual Itanium for PostgreSQL. I believe that the
PostgreSQL code is written for 32 bit and not optimized for the 64 bit
Itanium cpu. That makes me think that the Xeon system would be a better
choice.

Do any of you have thoughts on:

1. Straight performance capability
2. Price/Performance


This really depends on what you'll be doing. If your data set is very
large, then having a fast drive subsystem and lots of REALLY fast memory
matters more than CPU most of the time.

If you'll be doing lots of CPU intensive stuff, then having four CPUs is
likely to be nice.

It really kinda depends on what you're doing, and how fast the memory
busses / caches are in the two machines. The CPUs in a well tuned
database server tend to sit near idle mostly, while the drives spin and
the data in memory gets pumped around.

If the Itaniums have twice the memory bandwidth of the Xeons, it might
well be a wash for most loads.

So, what kinda profile are we looking at for your server?
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Nov 22 '05 #9

P: n/a
Doug McNaught wrote:
John Gibson <gi*@edgate.com> writes:
Assuming similar memory and disk sub-systems, I am considering a Quad
Xeon system vs. a Dual Itanium for PostgreSQL. I believe that the
PostgreSQL code is written for 32 bit and not optimized for the 64 bit
Itanium cpu. That makes me think that the Xeon system would be a
better choice.


Postgres runs on many 64-bit systems, including UltraSPARC, MIPS, and
Alpha, plus the Intel and AMD offerings. What makes you think it's
'not optimized'?

-Doug

Please help educate me. That is why I am asking. :)
....john

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 22 '05 #10

P: n/a
John Gibson wrote:
Assuming similar memory and disk sub-systems, I am considering a Quad
Xeon system vs. a Dual Itanium for PostgreSQL. I believe that the
PostgreSQL code is written for 32 bit and not optimized for the 64 bit
Itanium cpu. That makes me think that the Xeon system would be a better
choice.


Unfortunately, both have issues.

With Itanium, you absolutely have to use the Intel compiler. GCC is
beyond unoptimized for Itanium; you should expect 1/3rd the performance
with Postgres of what the Intel compiler would do. On the otherhand,
I've heard a few caveats about the Intel compiler that a lot of the
tricks they use are 100% designed for the Spec benchmarks and could
break real world code. Depends on what your stomach is for risk taking
on how many of the optimization flags you are willing to turn on.

Quad Xeon has it's own problems. The shared bus makes the 2P to 4P
scaling a bit problematic. The more intensive you use the memory
subsystem (which probably is the case with database uses), the bigger
hit you will take. As an example, SpecIntRate's 2->4 scaling for the
XeonMP is 75% but the SpecFPRate (SpecFP uses much larger datasets)
scaling drops to a mere 31%. Which memory usage model your DB would fall
under unfortunately can only be tested by you. Also throw in the need
for PAE to go over 2GB (~1GB for caching under most OS's) and you could
see some performance penalties there versus a 64-bit server.

But looking at the straight SpecIntRate numbers though, a 4P Xeon MP
will be faster than an 2P Itanium. There's enough of a performance gap
where penalties for shared memory bus and PAE won't make enough of a
difference.

4P XeonMP 2.8GHz 47.4
4P Xeon 2GHz 34.7
2P Itanium2 1.5GHz 25.4

As for pricing, you'll have to look that up yourself. :) Personally, I'm
very fond of Opteron servers due to the combination of 64-bit + ondie
memory controller + point-to-point inter-cpu connect. As a point of
comparison, 2P-4P Opteron Spec scaling numbers are 87% ad 76%.

Nov 22 '05 #11

P: n/a
James Moe wrote:
John Gibson wrote:

Assuming similar memory and disk sub-systems, I am considering a Quad
Xeon system vs. a Dual Itanium for PostgreSQL. I believe that the
PostgreSQL code is written for 32 bit and not optimized for the 64 bit
Itanium cpu. That makes me think that the Xeon system would be a better
choice.

The Itanic hasn't lived up to its marketing hype. The comparisons
I've seen between it and a 32-bit CPU show performance differences
primarily due to clock speeds. So far the only advantage of 64 bits is
address space. And because they are new, itanics cost much more.
So with 2 itanics you get a slight improvement. With 4 xeons you get
about 1.7x improvement over your current setup.


Here is an interesting article about the Opteron/Itanium issue:

http://www.theinquirer.net/?article=14038

--
Bruce Momjian | http://candle.pha.pa.us
pg***@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 22 '05 #12

P: n/a

On Feb 10, 2004, at 2:18 AM, Lincoln Yeoh wrote:
At 11:44 AM 2/9/2004 -0500, Doug McNaught wrote:
John Gibson <gi*@edgate.com> writes:
> Assuming similar memory and disk sub-systems, I am considering a Quad
> Xeon system vs. a Dual Itanium for PostgreSQL. I believe that the
> PostgreSQL code is written for 32 bit and not optimized for the 64

bit
> Itanium cpu. That makes me think that the Xeon system would be a
> better choice.


Postgres runs on many 64-bit systems, including UltraSPARC, MIPS, and
Alpha, plus the Intel and AMD offerings. What makes you think it's
'not optimized'?


<snip />
Unless you need cutting edge floating point performance I doubt you'd
want an Itanium (and even if you do, you might wish to consider
powerpc as well).


Speaking of PowerPC, has anyone out there run PostgreSQL on a G5
(either PowerMac or Xserve)? From looking at the specs, it seems it's
got great throughput in terms of moving data around.

Michael Glaesemann
grzm myrealbox com
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 22 '05 #13

P: n/a
>>>>> "JG" == John Gibson <gi*@edgate.com> writes:

JG> Hi, all.
JG> I need to upgrade my dual Xeon PostgreSQL engine.

JG> Assuming similar memory and disk sub-systems, I am considering a Quad
JG> Xeon system vs. a Dual Itanium for PostgreSQL. I believe that the

Save the money from the dual itanium or quad xeon and buy a dual xeon
but faster disks with a larger cache in the RAID controller, and
perhaps a dedicated RAID controller for the disk set that holds the
write-ahead log.

You're sure to find that you saturate the disk system faster than you
fill up even one CPU, let alone 4.

I assume that the box will be running *only* the database and any
other applications will run elsewhere.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: kh***@kciLink.com Rockville, MD +1-301-869-4449 x806
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 22 '05 #14

P: n/a
On Mon, Feb 09, 2004 at 12:46:58PM -0500, Christopher Browne wrote:
Lots of people have been running it on 64 bit systems for _years_ now.
The Digital Alpha architecture, for instance, was introduced in the
1992, and Sun UltraSPARC in 1995. PostgreSQL has been running well on
these sorts of systems for a lot of years now.


But actually, there are problems with using postgres as a 64 bit
application on Solaris. It works, and it's reliable, but I've never
seen any evidence that it helps anything (and I've looked plenty).

A

--
Andrew Sullivan | aj*@crankycanuck.ca
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism.
--Brad Holland

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 22 '05 #15

P: n/a
Hmm, do you mean 64 bit postgresql on Solaris-Sparc isn't significantly
better performance-wise than 32 bit postgresql on Solaris-Sparc?

Interesting.

How about very large databases?

At 07:17 AM 2/13/2004 -0500, Andrew Sullivan wrote:
On Mon, Feb 09, 2004 at 12:46:58PM -0500, Christopher Browne wrote:
Lots of people have been running it on 64 bit systems for _years_ now.
The Digital Alpha architecture, for instance, was introduced in the
1992, and Sun UltraSPARC in 1995. PostgreSQL has been running well on
these sorts of systems for a lot of years now.


But actually, there are problems with using postgres as a 64 bit
application on Solaris. It works, and it's reliable, but I've never
seen any evidence that it helps anything (and I've looked plenty).

A

--
Andrew Sullivan | aj*@crankycanuck.ca
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism.
--Brad Holland

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 22 '05 #16

P: n/a
On Fri, Feb 13, 2004 at 10:44:55PM +0800, Lincoln Yeoh wrote:
Hmm, do you mean 64 bit postgresql on Solaris-Sparc isn't significantly
better performance-wise than 32 bit postgresql on Solaris-Sparc?


Not in any test I've ever run. I haven't tried again lately, mind
you. And I never had the Sun compiler, which, for all I know, does a
better job with 64 bit binaries than gcc.

A

--
Andrew Sullivan | aj*@crankycanuck.ca
This work was visionary and imaginative, and goes to show that visionary
and imaginative work need not end up well.
--Dennis Ritchie

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 22 '05 #17

P: n/a
On Fri, 13 Feb 2004, Andrew Sullivan wrote:
On Mon, Feb 09, 2004 at 12:46:58PM -0500, Christopher Browne wrote:
Lots of people have been running it on 64 bit systems for _years_ now.
The Digital Alpha architecture, for instance, was introduced in the
1992, and Sun UltraSPARC in 1995. PostgreSQL has been running well on
these sorts of systems for a lot of years now.


But actually, there are problems with using postgres as a 64 bit
application on Solaris. It works, and it's reliable, but I've never
seen any evidence that it helps anything (and I've looked plenty).


I wonder if this would hold true when running 64 bit linux on Sparc
hardware... Could well be that the reason 64 bit is no faster than 32 bit
is that Solaris is just not a very fast platform for Postgresql, so any
improvements running 64 bit pgsql are lost in the Solaris/Postgresql mix.
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 22 '05 #18

P: n/a
scott.marlowe wrote:
On Fri, 13 Feb 2004, Andrew Sullivan wrote:
On Mon, Feb 09, 2004 at 12:46:58PM -0500, Christopher Browne wrote:
Lots of people have been running it on 64 bit systems for _years_ now.
The Digital Alpha architecture, for instance, was introduced in the
1992, and Sun UltraSPARC in 1995. PostgreSQL has been running well on
these sorts of systems for a lot of years now.


But actually, there are problems with using postgres as a 64 bit
application on Solaris. It works, and it's reliable, but I've never
seen any evidence that it helps anything (and I've looked plenty).


I wonder if this would hold true when running 64 bit linux on Sparc
hardware... Could well be that the reason 64 bit is no faster than 32 bit
is that Solaris is just not a very fast platform for Postgresql, so any
improvements running 64 bit pgsql are lost in the Solaris/Postgresql mix.


64-bits isn't faster than 32, and can be slower because of the longer
pointer length, decreasing cache performance. The major advantage to
64-bits is accessing more the 4gb of RAM.

--
Bruce Momjian | http://candle.pha.pa.us
pg***@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 22 '05 #19

P: n/a
On Fri, Feb 13, 2004 at 11:24:05AM -0500, Andrew Sullivan wrote:
On Fri, Feb 13, 2004 at 10:44:55PM +0800, Lincoln Yeoh wrote:
Hmm, do you mean 64 bit postgresql on Solaris-Sparc isn't significantly
better performance-wise than 32 bit postgresql on Solaris-Sparc?


Not in any test I've ever run. I haven't tried again lately, mind
you. And I never had the Sun compiler, which, for all I know, does a
better job with 64 bit binaries than gcc.


As a general rule 64 bit binaries tend to run slower than 32 bit
binaries on any given architecture. The 32 bit binaries still get to
use 64 bit data values if they feel so inclined, so that's nothing
special. But all the pointers in the 64 bit build are twice the size,
so the memory footprint is larger, it makes less efficient use of
cache, it takes longer to read data from main memory and so on. If you
need direct access to a lot of memory, and your application is
structured to use it, then a 64 bit model can be a big win, but
usually not otherwise.

Forte C is a lot better than gcc for Solaris/SPARC (unsurprisingly)
but 32 bit builds still seem a little faster than 64 bit builds. There
are some benchmarks I looked at recently that show that, but I don't
seem to be able to find the article right now.

Cheers,
Steve

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 22 '05 #20

P: n/a
On Fri, Feb 13, 2004 at 12:19:39PM -0500, Bruce Momjian wrote:
64-bits isn't faster than 32, and can be slower because of the longer
pointer length, decreasing cache performance. The major advantage to
64-bits is accessing more the 4gb of RAM.


I note, however, that all the Sun experts say you should get your
database applications optimised for 64 bits because you can ship
around more data at a time. I have no clue what they're basing it
on, though.

A

--
Andrew Sullivan | aj*@crankycanuck.ca
The plural of anecdote is not data.
--Roger Brinner

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Nov 22 '05 #21

P: n/a
Martha Stewart called it a Good Thing when aj*@crankycanuck.ca (Andrew Sullivan) wrote:
On Fri, Feb 13, 2004 at 12:19:39PM -0500, Bruce Momjian wrote:
64-bits isn't faster than 32, and can be slower because of the longer
pointer length, decreasing cache performance. The major advantage to
64-bits is accessing more the 4gb of RAM.


I note, however, that all the Sun experts say you should get your
database applications optimised for 64 bits because you can ship
around more data at a time. I have no clue what they're basing it
on, though.


Well, presumably if you are copying values in and out of registers, it
is preferable to use 64 bit registers, thereby shifting around 64 bits
at a time. If that seems underwhelming, well, that might explain
Solaris...
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://www.ntlug.org/~cbbrowne/emacs.html
"[In 'Doctor' mode], I spent a good ten minutes telling Emacs what I
thought of it. (The response was, 'Perhaps you could try to be less
abusive.')" -- Matt Welsh
Nov 22 '05 #22

P: n/a
Wouldn't you only care about 64-bit Postgres if you wanted to make
shared_buffers bigger than 4G?

Various other posters have commented about the sweet-spot for
shared_buffers being ~ 100-200M (or thereabouts).

So it seems to me that there is nothing to be gained using a 64-bit
binary with the current or previous Pg releases. However, with the new
cache replacement system being used in 7.5devel, the situation *may* be
different (wonder if anyone has tried this out yet?).

regards

Mark
Andrew Sullivan wrote:
On Mon, Feb 09, 2004 at 12:46:58PM -0500, Christopher Browne wrote:

Lots of people have been running it on 64 bit systems for _years_ now.
The Digital Alpha architecture, for instance, was introduced in the
1992, and Sun UltraSPARC in 1995. PostgreSQL has been running well on
these sorts of systems for a lot of years now.


But actually, there are problems with using postgres as a 64 bit
application on Solaris. It works, and it's reliable, but I've never
seen any evidence that it helps anything (and I've looked plenty).

A

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 22 '05 #23

P: n/a
Mark Kirkwood <ma****@paradise.net.nz> writes:
So it seems to me that there is nothing to be gained using a 64-bit
binary with the current or previous Pg releases. However, with the new
cache replacement system being used in 7.5devel, the situation *may* be
different (wonder if anyone has tried this out yet?).


Quite honestly, I suspect we may be wasting our time hacking the
Postgres buffer replacement algorithm at all. There are a bunch of
reasons why the PG shared buffer arena should never be more than a
small fraction of physical RAM, and under those conditions the cache
replacement algorithm that will matter is the kernel's, not ours.

I stand ready to be proven wrong, of course ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 22 '05 #24

P: n/a
On Fri, Feb 13, 2004 at 10:46:18PM -0500, Tom Lane wrote:
Quite honestly, I suspect we may be wasting our time hacking the
Postgres buffer replacement algorithm at all. There are a bunch of
reasons why the PG shared buffer arena should never be more than a
small fraction of physical RAM, and under those conditions the cache
replacement algorithm that will matter is the kernel's, not ours.


Well, unless the Postgres cache is more efficient than the OS's, no?.
You could then use the nocache filesystem option, and just let
Postgres handle the whole thing. Of course, that's a pretty big
unless, and not one that I'm volunteering to make go away!

A

--
Andrew Sullivan

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Nov 22 '05 #25

P: n/a
Tom Lane wrote:
Mark Kirkwood <ma****@paradise.net.nz> writes:
So it seems to me that there is nothing to be gained using a 64-bit
binary with the current or previous Pg releases. However, with the new
cache replacement system being used in 7.5devel, the situation *may* be
different (wonder if anyone has tried this out yet?).


Quite honestly, I suspect we may be wasting our time hacking the
Postgres buffer replacement algorithm at all. There are a bunch of
reasons why the PG shared buffer arena should never be more than a
small fraction of physical RAM, and under those conditions the cache
replacement algorithm that will matter is the kernel's, not ours.

I stand ready to be proven wrong, of course ...


Let's see,

I'm not actually claiming you're wrong. But it seems that the new ARC
code together with the background writer is at least as good as the OS
buffer cache. Looking at these tests:

http://developer.postgresql.org/~wieck/PGvsOSbuffers/

I see a 9.8% and 18.9% improvement on the 90th percentile of transaction
response time comparing 1000 to 50000 shared buffers. And a 17.8% and
21.8% improvement comparing 10000 to 50000 shared buffers. The old
school "sweet spot" of shared_buffers is the loser, interesting, eh?

I guess that the higher buffer hit rate pays off in this particular test
scenario, which does not look at average response times or overall
throughput but aims to satisfy 90% of all requests within 5 seconds.
Note that the server is in all 6 test runs slightly overloaded as it
cannot meet this requirement ever. However, the total number of
processed transactions is highest for 50000 buffers, but only marginal.
Jan

--
#================================================= =====================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================= = Ja******@Yahoo.com #
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 22 '05 #26

This discussion thread is closed

Replies have been disabled for this discussion.