| From: | Brent Wood <b(dot)wood(at)niwa(dot)co(dot)nz> |
|---|---|
| To: | "Uwe C(dot) Schroeder" <uwe(at)oss4u(dot)com> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: UltraSPARC versus AMD |
| Date: | 2005-04-26 02:19:57 |
| Message-ID: | 20050426141447.K58648@storm-user.niwa.co.nz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mike Mascari | 2005-04-26 02:21:02 | Re: UltraSPARC versus AMD |
| Previous Message | Eric B. Ridge | 2005-04-26 01:49:43 | Re: Corruption on production system |