It's also possible that the single SATA drive you were testing (or the
controller it was attached to) is lying about fsync and performing write
caching behind your back, whereas your new controller and drives are
not.
You'll find a lot more info on the archives of this list about it, but
basically if your application is committing a whole lot of small
transactions, then it will run fast (but not safely) on a drive which
lies about fsync, but slower on a better disk subsystem which doesn't
lie about fsync.
Try running a test with fsync=off with your new equipment and if it
suddenly starts running faster, then you know that's the problem.
You'll either have a choice of losing all of your data the next time the
system shuts down uncleanly but being fast, or of running slow, or of
fixing the applications to use chunkier transactions.
-- Mark
On Fri, 2006-04-28 at 13:36 -0400, Vivek Khera wrote:
> On Apr 28, 2006, at 11:37 AM, Erik Myllymaki wrote:
>
> > When I had this installed on a single SATA drive running from the
> > PE1800's on-board SATA interface, this operation took anywhere from
> > 65-80 seconds.
> >
> > With my new RAID card and drives, this operation took 272 seconds!?
>
> switch it to RAID10 and re-try your experiment. if that is fast,
> then you know your raid controller does bad RAID5.
>
> anyhow, I have in one server (our office mail server and part-time
> development testing box) an adaptec SATA RAID from dell. it is
> configured for RAID5 and does well for normal office stuff, but when
> we do postgres tests on it, it just is plain old awful.
>
> but I have some LSI based cards on which RAID5 is plenty fast and
> suitable for the DB, but those are SCSI.
>
> For what it is worth, the Dell PE1850 internal PERC4/Si card is
> wicked fast when hooked up with a pair of U320 SCSI drives.
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq