Обсуждение: UltraSPARC versus AMD
I just got done comparing SPECMarks (on spec.org) between Sun's AMD entry level servers versus similarly configured UltraSPARCs versus desktop AMD based machines. Sun's AMD machines are twice as fast as their UItraSPARCs, for approximately the same price. What a hoot. Rick
On Fri, 2005-04-22 at 09:48, Richard_D_Levine@raytheon.com wrote: > I just got done comparing SPECMarks (on spec.org) between Sun's AMD entry > level servers versus similarly configured UltraSPARCs versus desktop AMD > based machines. Sun's AMD machines are twice as fast as their UItraSPARCs, > for approximately the same price. What a hoot. Wow. I'd certainly like to see the numbers and such from your benchmarks. I have to say I'm not surprised, the 64 bit AMD chips are quite impressive pieces of hardware.
pgsql-general-owner@postgresql.org wrote on 04/22/2005 10:08:46 AM: > On Fri, 2005-04-22 at 09:48, Richard_D_Levine@raytheon.com wrote: > > I just got done comparing SPECMarks (on spec.org) between Sun's AMD entry > > level servers versus similarly configured UltraSPARCs versus desktop AMD > > based machines. Sun's AMD machines are twice as fast as their UItraSPARCs, > > for approximately the same price. What a hoot. > > Wow. I'd certainly like to see the numbers and such from your > benchmarks. I have to say I'm not surprised, the 64 bit AMD chips are > quite impressive pieces of hardware. The benchmarks aren't mine, they're standard performance evaluation (SPEC) defined by spec.org http://www.spec.org Click on the desired benchmark (I was referring to the CPU benchmarks) and click on "published results". The manufacturers (Sun, Dell, HP, etc.) buy the benchmarks, configure their best compiler for speed, run them, and submit the results. My point is that Sun ran the benchmarks, under very strict rules set forth by SPEC. Rick > > ---------------------------(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
Richard_D_Levine@raytheon.com wrote: > I just got done comparing SPECMarks (on spec.org) between Sun's AMD entry > level servers versus similarly configured UltraSPARCs versus desktop AMD > based machines. Sun's AMD machines are twice as fast as their UItraSPARCs, > for approximately the same price. What a hoot. Not that surprising. UltraSparcs haven't been "fast" in a long time. They just scale really well. Sincerely, Joshua D. Drake > > Rick > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Richard_D_Levine@raytheon.com writes: > I just got done comparing SPECMarks (on spec.org) between Sun's AMD entry > level servers versus similarly configured UltraSPARCs versus desktop AMD > based machines. Sun's AMD machines are twice as fast as their UItraSPARCs, > for approximately the same price. What a hoot. It's not surprising. The "interesting" efforts that Sun has been putting into CPUs lately have gone into the new "Niagara" thing which isn't going into low end UltraSPARCs. AMD has gotten a lot of the ex-Digital folk, and ex-Alpha technologies, and has been able to get that stuff into lower priced systems, from whence is what we can see... -- (format nil "~S@~S" "cbbrowne" "acm.org") http://www.ntlug.org/~cbbrowne/sap.html Rules of the Evil Overlord #78. "I will not tell my Legions of Terror "And he must be taken alive!" The command will be: ``And try to take him alive if it is reasonably practical.''" <http://www.eviloverlord.com/>
Chris Browne wrote: > Richard_D_Levine@raytheon.com writes: > >>I just got done comparing SPECMarks (on spec.org) between Sun's AMD entry >>level servers versus similarly configured UltraSPARCs versus desktop AMD >>based machines. Sun's AMD machines are twice as fast as their UItraSPARCs, >>for approximately the same price. What a hoot. The focus should not just be on SPARC vs AMD64. The AMD64 chips outperform Intel P4 and Xeon handily as well, using ooomph per dollar, oooomph per Megahertz, or most other measures. I'm certainly not complaining, it just appears AMD64 is an outstanding value these days. We purchased 2 laptops, one P4, one AMD64 from a linux-friendly vendor to use as software demo boxes. The AMD CPU speed is about 60% of the Intel P4 CPU speed, both have same amount of RAM & Disk, both have the same video controller. The intel laptop was more expensive, but the AMD64 box clearly outperforms it with both postgresql and our weather/flight tracking applications. Josh
Aceshardware.com has a good UI for looking at Spec scores. They imported all the results into their DB for easily comparisons between processors. Single CPU (individual queries): http://www.aceshardware.com/SPECmine/index.jsp?b=0&s=0&v=4&if=0&if=1&if=2&a=0&a=1&a=2&a=3&a=5&a=6&a=7&ncf=1&nct=1&cpcf=1&cpct=1&mf=1&mt=4000&o=0&o=1 Quad CPU SMP performance: http://www.aceshardware.com/SPECmine/index.jsp?b=1&s=0&v=4&if=0&if=1&if=2&a=0&a=1&a=2&a=3&a=5&a=6&a=7&ncf=1&nct=4&cpcf=1&cpct=4&mf=250&mt=3800&o=0&o=1 Money is no object performance: http://www.aceshardware.com/SPECmine/index.jsp?b=1&s=0&v=4&if=0&if=1&if=2&a=0&a=1&a=2&a=3&a=5&a=6&a=7&ncf=1&nct=256&cpcf=1&cpct=256&mf=250&mt=3800&o=0&o=1 The numbers don't have the latest dual core Opterons yet. (Don't see them on spec.org yet either.) My random guess right now, 4x2 system would probably be about 140 SpecINT_rate. It's looking like it's faster than have a DC Opteron w/ 1 memory bank versus Dual Opteron w/ 2 memory bank because the interconnect between cores inside a DC CPU is so much faster than the HT motherboard connect. Richard_D_Levine@raytheon.com wrote: > > pgsql-general-owner@postgresql.org wrote on 04/22/2005 10:08:46 AM: > > >>On Fri, 2005-04-22 at 09:48, Richard_D_Levine@raytheon.com wrote: >> >>>I just got done comparing SPECMarks (on spec.org) between Sun's AMD > > entry > >>>level servers versus similarly configured UltraSPARCs versus desktop > > AMD > >>>based machines. Sun's AMD machines are twice as fast as their > > UItraSPARCs, > >>>for approximately the same price. What a hoot. >> >>Wow. I'd certainly like to see the numbers and such from your >>benchmarks. I have to say I'm not surprised, the 64 bit AMD chips are >>quite impressive pieces of hardware. > > > The benchmarks aren't mine, they're standard performance evaluation (SPEC) > defined by spec.org > > http://www.spec.org > > Click on the desired benchmark (I was referring to the CPU benchmarks) and > click on "published results". > > The manufacturers (Sun, Dell, HP, etc.) buy the benchmarks, configure their > best compiler for speed, run them, and submit the results. My point is > that Sun ran the benchmarks, under very strict rules set forth by SPEC. > > Rick > > >>---------------------------(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 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq >
Looked on AMD's website. 132 for 4x875 on Windows, 126 on Linux. (Probably Intel compiler on Windows, gcc on Linux.) That gets AMD into the $100K 16+ processor Sun system area in terms of performance. Of course, Sun still has a crapload of other uptime/reliability features built-in to their systems. William Yu wrote: > The numbers don't have the latest dual core Opterons yet. (Don't see > them on spec.org yet either.) My random guess right now, 4x2 system > would probably be about 140 SpecINT_rate. It's looking like it's faster > than have a DC Opteron w/ 1 memory bank versus Dual Opteron w/ 2 memory > bank because the interconnect between cores inside a DC CPU is so much > faster than the HT motherboard connect.
Well, you overlook one thing there. SUN has always has a really good I/O performance - something far from negligible for a database application. A lot of the PC systems lack that kind of I/O thruput. Just compare a simple P4 with ATAPI drives to the same P4 with 320 SCSI drives - the speed difference, particularly using any *nix, is surprisingly significant and easily visible with the bare eye. There is a reason why a lot of the financial/insurance institutions (having a lot of transactions in their DB applications) use either IBM mainframes or SUN E10k's :-) Personally I think a weaker processor with top of the line I/O will perform better for DB apps than the fastest processor with crappy I/O. i guess the "my $0.02" is in order here :-) UC On Saturday 23 April 2005 01:06, William Yu wrote: > Looked on AMD's website. 132 for 4x875 on Windows, 126 on Linux. > (Probably Intel compiler on Windows, gcc on Linux.) That gets AMD into > the $100K 16+ processor Sun system area in terms of performance. Of > course, Sun still has a crapload of other uptime/reliability features > built-in to their systems. > > William Yu wrote: > > The numbers don't have the latest dual core Opterons yet. (Don't see > > them on spec.org yet either.) My random guess right now, 4x2 system > > would probably be about 140 SpecINT_rate. It's looking like it's faster > > than have a DC Opteron w/ 1 memory bank versus Dual Opteron w/ 2 memory > > bank because the interconnect between cores inside a DC CPU is so much > > faster than the HT motherboard connect. > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) -- Open Source Solutions 4U, LLC 2570 Fleetwood Drive Phone: +1 650 872 2425 San Bruno, CA 94066 Cell: +1 650 302 2405 United States Fax: +1 650 872 2417
Oh I'm sure in the past, Sun had way better I/O performance. But the gap at least for entry-level servers has closed quite a lot with HT, Inifiband, PCI-X, PCIe and so on available on for x86. Most x86 2P/4P server MBs I've seen seem to have 2 PCI-X bridges, 1 PCI bridge and separate bridges for 2x Gigabit Ethernet -- easily 2+GB of I/O available. Now the latest craze is PCIe. For example, the Tyan S2895 has 3 HT (6.4GB/s) connections used for I/O. #1 has PCIe x16 (8GB) + GigE, #2 has PCIe x16 + GigE + SATA + IDE, #3 has PCI-X 133 (1GB) + PCI-X 100 (.75GB) + PCI. If you could find the right cards to max out the system, we're looking at 14+ GB/s of I/O. Unfortunately, the PCIe SCSI RAID controller selection is pretty sparse right now. There's a PCIe x8 (4GB/s) card from Intel but it's only has 2 U320 channels so it's way underutilizing the available bandwidth. As for why financial/insurance institutions use IBMs or Suns -- I would suggest limited choice is a bigger issue than any specific sub-system performance factor. A nationwide bank doesn't have any choice except to pick a monster 100+ processor machine because anything slower couldn't handle their 20,000 employees. Not many options really. Plus, people in big companies tend to make safe decisions -- get the company with the most name value so you don't get fired if the machine turns out to be a lemon. Uwe C. Schroeder wrote: > Well, you overlook one thing there. SUN has always has a really good I/O > performance - something far from negligible for a database application. > A lot of the PC systems lack that kind of I/O thruput. > Just compare a simple P4 with ATAPI drives to the same P4 with 320 SCSI drives > - the speed difference, particularly using any *nix, is surprisingly > significant and easily visible with the bare eye. > There is a reason why a lot of the financial/insurance institutions (having a > lot of transactions in their DB applications) use either IBM mainframes or > SUN E10k's :-) > Personally I think a weaker processor with top of the line I/O will perform > better for DB apps than the fastest processor with crappy I/O. > > i guess the "my $0.02" is in order here :-) > > UC > > > On Saturday 23 April 2005 01:06, William Yu wrote: > >>Looked on AMD's website. 132 for 4x875 on Windows, 126 on Linux. >>(Probably Intel compiler on Windows, gcc on Linux.) That gets AMD into >>the $100K 16+ processor Sun system area in terms of performance. Of >>course, Sun still has a crapload of other uptime/reliability features >>built-in to their systems. >> >>William Yu wrote: >> >>>The numbers don't have the latest dual core Opterons yet. (Don't see >>>them on spec.org yet either.) My random guess right now, 4x2 system >>>would probably be about 140 SpecINT_rate. It's looking like it's faster >>>than have a DC Opteron w/ 1 memory bank versus Dual Opteron w/ 2 memory >>>bank because the interconnect between cores inside a DC CPU is so much >>>faster than the HT motherboard connect. >> >>---------------------------(end of broadcast)--------------------------- >>TIP 2: you can get off all lists at once with the unregister command >> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > > > -- > Open Source Solutions 4U, LLC 2570 Fleetwood Drive > Phone: +1 650 872 2425 San Bruno, CA 94066 > Cell: +1 650 302 2405 United States > Fax: +1 650 872 2417 > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) >
As someone who works in a nationwide bank, let me tell you why we choose IBM and Sun hardware: support. If we want to get a server for a project, we can't just go get the most cost-efficient thing out there for the job. We have a short list of servers that can be picked from, and that's it. A given server makes it onto that list if and only if it can be supported by a vendor in a matter of hours for at least 3 years. We don't always purchase that support, but bank policy says it has to be an option. We don't generally purchase monster machines. Sure, there are some mainframes, but they are few and far between. Everything else doesn't really have anything more than 32 procs. On Apr 23, 2005, at 2:58 AM, William Yu wrote: > As for why financial/insurance institutions use IBMs or Suns -- I > would suggest limited choice is a bigger issue than any specific > sub-system performance factor. A nationwide bank doesn't have any > choice except to pick a monster 100+ processor machine because > anything slower couldn't handle their 20,000 employees. Not many > options really. Plus, people in big companies tend to make safe > decisions -- get the company with the most name value so you don't get > fired if the machine turns out to be a lemon.
32 proc IBM boxes > 100+ SUN boxes. :) Ben wrote: > We don't generally purchase monster machines. Sure, there are some > mainframes, but they are few and far between. Everything else doesn't > really have anything more than 32 procs.
I am looking at options for a customer with an installed base of ~5000 Sun workstations running 400-500MHz UltraSPARCs. They're not getting the performance they need. They shipped me two Tadpole Bullfrog machines, a Bullfrog I and a Bullfrog II for evaluation. http://www.tadpole.com 1.28GHz single or dual CPU UltraSPARCs. On board SCSI, but they installed IDE drives instead. In my *utter* lack of enthusiasm over this option, I was gathering ammunition for better hardware. I went to spec.org for speed comparisons, and sun.com for price comparisons. Sun's *entry* level servers are more powerful when running AMD CPUs. I note with interest and appreciation comments about the bigger iron from Sun and IBM. That's not what I'm in the market for, but good info as always. My evaluation is that a single or dual core AMD 64 Athlon in a rugged laptop is going to give a performance enhancement (SPECMark wise) of about an order of magnitude over their current hardware base. And it's cheaper. The current hardware base contains a 10k SCSI Fast Wide Ultra single disk on a 440MHz CPU as well as a 7200 IDE on a 500MHz CPU. The SCSI with the slower CPU runs the application 8% faster. Obviously I'll need to work on the proper I/O subsystem because that's apparently more of a limiter than the CPU speed. Cheers, Rick pgsql-general-owner@postgresql.org wrote on 04/23/2005 11:02:17 AM: > As someone who works in a nationwide bank, let me tell you why we > choose IBM and Sun hardware: support. If we want to get a server for a > project, we can't just go get the most cost-efficient thing out there > for the job. We have a short list of servers that can be picked from, > and that's it. A given server makes it onto that list if and only if it > can be supported by a vendor in a matter of hours for at least 3 years. > We don't always purchase that support, but bank policy says it has to > be an option. > > We don't generally purchase monster machines. Sure, there are some > mainframes, but they are few and far between. Everything else doesn't > really have anything more than 32 procs. > > On Apr 23, 2005, at 2:58 AM, William Yu wrote: > > > As for why financial/insurance institutions use IBMs or Suns -- I > > would suggest limited choice is a bigger issue than any specific > > sub-system performance factor. A nationwide bank doesn't have any > > choice except to pick a monster 100+ processor machine because > > anything slower couldn't handle their 20,000 employees. Not many > > options really. Plus, people in big companies tend to make safe > > decisions -- get the company with the most name value so you don't get > > fired if the machine turns out to be a lemon. > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster
Richard_D_Levine@raytheon.com wrote: > In my *utter* lack of enthusiasm over this option, I was gathering > ammunition for better hardware. I went to spec.org for speed comparisons, > and sun.com for price comparisons. Sun's *entry* level servers are more > powerful when running AMD CPUs. Just in case people still hold a bias against CISC processors capable of running x86 code as necessarily inferior to more expensive 64-bit RISC processors, in spite of the overwhelmingly obvious specint results to the contrary, I'd like to offer up this little baby: http://www.cray.com/products/xt3/index.html Something everyone should have in their office... Mike Mascari
Mike Mascari <mascarm@mascari.com> wrote on 04/25/2005 09:21:02 PM: > Richard_D_Levine@raytheon.com wrote: > > In my *utter* lack of enthusiasm over this option, I was gathering > > ammunition for better hardware. I went to spec.org for speed comparisons, > > and sun.com for price comparisons. Sun's *entry* level servers are more > > powerful when running AMD CPUs. > > Just in case people still hold a bias against CISC processors capable of > running x86 code as necessarily inferior to more expensive 64-bit RISC > processors, in spite of the overwhelmingly obvious specint results to > the contrary, I'd like to offer up this little baby: > > http://www.cray.com/products/xt3/index.html > > Something everyone should have in their office... I RTFA. Oh my god. Favorite excerpts: AMD Opteron Processor The industry leading Opteron microprocessor offers a number of advantages for superior performance and scalability. The Opteron processor's on-chip, highly associative 1 MB cache supports aggressive out-of-order execution and can issue up to nine instructions simultaneously. The integrated memory controller eliminates the need for a separate Northbridge memory controller chip, providing an extremely low latency path to local memory—less than 60 nanoseconds. This is a significant performance advantage, particularly for algorithms that require irregular memory access. The 128-bit wide memory controller provides 6.4 GB/s local memory bandwidth per processor, or more than one byte per FLOP. This balance brings a performance advantage to algorithms that stress local memory bandwidth. Service PEs run a full Linux™ distribution. Service PEs can be configured to provide login, I/O, system, or network services. Scalable Operating System The Cray XT3 operating system UNICOS/lc is designed to run large complex applications and scale efficiently to 30,000 processors. The I/O architecture consists of data RAIDs connected directly to I/O PEs which reside on the high-speed interconnect. The Lustre file system manages the striping of file operations across these RAIDs. > > Mike Mascari
On Sat, 23 Apr 2005, Uwe C. Schroeder wrote: > Well, you overlook one thing there. SUN has always has a really good I/O > performance - something far from negligible for a database application. > A lot of the PC systems lack that kind of I/O thruput. > Just compare a simple P4 with ATAPI drives to the same P4 with 320 SCSI drives > - the speed difference, particularly using any *nix, is surprisingly > significant and easily visible with the bare eye. > There is a reason why a lot of the financial/insurance institutions (having a > lot of transactions in their DB applications) use either IBM mainframes or > SUN E10k's :-) > Personally I think a weaker processor with top of the line I/O will perform > better for DB apps than the fastest processor with crappy I/O. > > i guess the "my $0.02" is in order here :-) > Given that "basic" SQL is getting more analytical in capability, esp if you look at PostGIS/Postgres or Oracle/Informix/DB2 with their respective spatial extensions, then spatial overlays with several tables with polygons with large no's of vertices can get cpu bound as well as the more traditional DB I/O bound limitations. But, I agree that generally I/O is a more typical db issue. Brent Wood
> -----Original Message----- > From: pgsql-general-owner@postgresql.org > [mailto:pgsql-general-owner@postgresql.org]On Behalf Of Brent Wood > Sent: Monday, April 25, 2005 8:20 PM > To: Uwe C. Schroeder > Cc: pgsql-general@postgresql.org > Subject: Re: [GENERAL] UltraSPARC versus AMD > > > > > On Sat, 23 Apr 2005, Uwe C. Schroeder wrote: > > > Well, you overlook one thing there. SUN has always has a > really good I/O > > performance - something far from negligible for a database > application. Am i dreaming?, Solaris really good I/O performance? Have your heard of slowlaris? May be you mean hardware performance, combined with a great OS (BSD or Linux) I had to "upgrade" many Sunfire 280 (running slowlaris [8|9]) to BSD because of poor DB performance, after the upgrade, all run flawlessly. I only wish a had made this switch before Just my $0.02 > > A lot of the PC systems lack that kind of I/O thruput. > > Just compare a simple P4 with ATAPI drives to the same P4 > with 320 SCSI drives > > - the speed difference, particularly using any *nix, is surprisingly > > significant and easily visible with the bare eye. We are talking about server or pc?, we run postgres on several HP dl380 (5i SCSI controller) with great performance > > There is a reason why a lot of the financial/insurance > institutions (having a > > lot of transactions in their DB applications) use either > IBM mainframes or > > SUN E10k's :-) > > Personally I think a weaker processor with top of the line > I/O will perform > > better for DB apps than the fastest processor with crappy I/O. > > > > i guess the "my $0.02" is in order here :-) > > > i totally agree with this --- Miguel
pgsql-general-owner@postgresql.org wrote on 04/25/2005 09:19:57 PM: > > > On Sat, 23 Apr 2005, Uwe C. Schroeder wrote: > > > Well, you overlook one thing there. SUN has always has a really good I/O > > performance - something far from negligible for a database application. > > A lot of the PC systems lack that kind of I/O thruput. > > Just compare a simple P4 with ATAPI drives to the same P4 with 320 > SCSI drives > > - the speed difference, particularly using any *nix, is surprisingly > > significant and easily visible with the bare eye. > > There is a reason why a lot of the financial/insurance > institutions (having a > > lot of transactions in their DB applications) use either IBM mainframes or > > SUN E10k's :-) > > Personally I think a weaker processor with top of the line I/O will perform > > better for DB apps than the fastest processor with crappy I/O. > > > > i guess the "my $0.02" is in order here :-) > > > > Given that "basic" SQL is getting more analytical in capability, esp if > you look at PostGIS/Postgres or Oracle/Informix/DB2 with their respective > spatial extensions, then spatial overlays with several tables with > polygons with large no's of vertices can get cpu bound as well as the more > traditional DB I/O bound limitations. > > But, I agree that generally I/O is a more typical db issue. I also agree that I/O is the bigger problem, but for me the bottom line is that there has been a power/price inversion in CPUs. AMD chips are cheaper and more powerful than Intel, which are cheaper and more powerful than lower-end UltraSPARCs. I can't speak for higher-end UltraSPARCs (someone mentioned a Niagara chip, which may or may not be the new UltraSPARC IV.) I think it speaks volumes that Cray's top of the line machine uses 30,000 Opterons with 240 *terabytes* of RAM (8GB/CPU). I also agree that spatial DB operations are compute intensive for floating point trigonometric functions, so why not put the cheapest and best in a low-end server, especially a map server? If someone mentions $7k again.... Rick > > Brent Wood > > ---------------------------(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
Sun's stock was at $65.00 in late 2000 and has rocketed to $3.50. I think somebody else besides us noticed too. pgsql-general-owner@postgresql.org wrote on 04/26/2005 01:12:49 PM: > > > > -----Original Message----- > > From: pgsql-general-owner@postgresql.org > > [mailto:pgsql-general-owner@postgresql.org]On Behalf Of Brent Wood > > Sent: Monday, April 25, 2005 8:20 PM > > To: Uwe C. Schroeder > > Cc: pgsql-general@postgresql.org > > Subject: Re: [GENERAL] UltraSPARC versus AMD > > > > > > > > > > On Sat, 23 Apr 2005, Uwe C. Schroeder wrote: > > > > > Well, you overlook one thing there. SUN has always has a > > really good I/O > > > performance - something far from negligible for a database > > application. > > Am i dreaming?, > Solaris really good I/O performance? > > Have your heard of slowlaris? > > May be you mean hardware performance, combined with a great OS (BSD or > Linux) > > I had to "upgrade" many Sunfire 280 (running slowlaris [8|9]) to BSD because > of poor DB performance, after the upgrade, all run flawlessly. > I only wish a had made this switch before > Just my $0.02 > > > > > A lot of the PC systems lack that kind of I/O thruput. > > > Just compare a simple P4 with ATAPI drives to the same P4 > > with 320 SCSI drives > > > - the speed difference, particularly using any *nix, is surprisingly > > > significant and easily visible with the bare eye. > > We are talking about server or pc?, we run postgres on several HP dl380 (5i > SCSI controller) with great performance > > > > There is a reason why a lot of the financial/insurance > > institutions (having a > > > lot of transactions in their DB applications) use either > > IBM mainframes or > > > SUN E10k's :-) > > > Personally I think a weaker processor with top of the line > > I/O will perform > > > better for DB apps than the fastest processor with crappy I/O. > > > > > > i guess the "my $0.02" is in order here :-) > > > > > > > i totally agree with this > --- > Miguel > > ---------------------------(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