Re: RAID + PostgreSQL? - Mailing list pgsql-general

From Franz.Rasper@izb.de
Subject Re: RAID + PostgreSQL?
Date
Msg-id 11EC9A592C31034C88965C87AF18C2A709BEBA@m0000s61
Whole thread Raw
In response to RAID + PostgreSQL?  ("MG" <pgsql-general@carladata.de>)
Responses Re: RAID + PostgreSQL?
List pgsql-general
How much I/O Performance do you need ?

READ Performance ? Write Performance ?

I need an fast and reliable RAID Controller (harddisks have to be hot plug,
automatic rebuild etc.)
and I have to say that the HP DL 380 G 4 with Battery Backup Write Cache ,
FAST U320 HDs,
some gigs ram (chipkill is a nice feature), redundant fans and power
supplies is a good database server.
Unfortunately I had no chance to test the HP DL 385.

Greetings,

-Franz

-----Ursprüngliche Nachricht-----
Von: Scott Marlowe [mailto:smarlowe@g2switchworks.com]
Gesendet: Dienstag, 27. Juni 2006 17:45
An: Franz.Rasper@izb.de
Cc: teolupus@gmail.com; pgsql general
Betreff: Re: [GENERAL] RAID + PostgreSQL?


On Tue, 2006-06-27 at 08:05, Franz.Rasper@izb.de wrote:
> I have here HP DL 380 G3 und HP DL 380 G4. (here Smart Array 5i and Smart
> Array 6i)
> Maybe there are problems with old linux kernel (but as far as i know >
> 2.4.27)
> I dont know about such performance problems, maybe the conrollers are
faster
> under windows.
>
> The battery backup write cache are very import for inserts.
>
> You should use for performance test with dd under linux larger blocksizes,
> but you should compare postgresql under linux and windows (selects,
update,
> inserts, etc.)

Note that having the latest driver usually helps a lot too.

The LSI megaraid was solid but a mediocre performer with the older 1.18
driver, but the 2.x series driver was much faster when I tested it.

---------------------------(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

pgsql-general by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: UUID's as primary keys
Next
From: Thomas Hallgren
Date:
Subject: Re: UUID's as primary keys