Re: UltraSPARC versus AMD

From: Richard_D_Levine(at)raytheon(dot)com
To: Brent Wood <b(dot)wood(at)niwa(dot)co(dot)nz>
Cc: pgsql-general(at)postgresql(dot)org, pgsql-general-owner(at)postgresql(dot)org, "Uwe C(dot) Schroeder" <uwe(at)oss4u(dot)com>
Subject: Re: UltraSPARC versus AMD
Date: 2005-04-26 18:59:26
Message-ID: OF98652429.CD511E59-ON05256FEF.0067420A-05256FEF.006851C0@ftw.us.ray.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

pgsql-general-owner(at)postgresql(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Michael Fuhr 2005-04-26 19:04:47 Re: About index - "a query or data manipulation command can use at most one index per table"
Previous Message Carlos Gustavo fischer 2005-04-26 18:18:55 Query Designer