From: Adarsh Sharma <adarsh.sharma@orkash.com>
To: Craig Ringer <ringerc@ringerc.id.au>
Cc: pgsql-performance@postgresql.org
Subject: Re: Parameters for PostgreSQL
Date: Thu, 04 Aug 2011 10:45:41 +0530
Message-ID: <4E3A2AFD.1090106@orkash.com> (raw)
In-Reply-To: <4E3A1A0B.5090809@ringerc.id.au>
References: <OF4401A47F.8A79A9ED-ON652578DF.00422697-652578DF.0042CB3B@ibsplc.com>
<4E373D76.9020800@postnewspapers.com.au>
<OFB5D52348.1A6D34E9-ON652578E2.00137B30-652578E2.001450FD@ibsplc.com>
<4E3A1A0B.5090809@ringerc.id.au>
I think RAID 10 is best among all the RAID Levels.
Thanks
Craig Ringer wrote:
> On 04/08/11 11:42, Jayadevan M wrote:
>> Hello,
>>
>> >The most important spec has been omitted. What's the storage subsystem?
>> We have storage on SAN, RAID 5.
>
> RAID 5? That's *really* not ideal for database workloads, either Pg or
> Oracle, unless your RAID 5 storage backend has enough battery-backed
> write cache to keep huge amounts of writes in RAM and reorder them
> really effectively.
>
> I hope each RAID 5 LUN is only across a few disks and is layered with
> RAID 1, though. RAID 5 becomes less reliable than using a single disk
> when used with too many HDDs, because the probability of a double-disk
> failure becomes greater than that of a single standalone disk failing.
> After being bitten by that a few times, these days I'm using RAID 6 in
> most cases where RAID 10 isn't practical.
>
> In any case, "SAN" can be anything from a Linux box running an iSCSI
> target on top of a RAID 5 `md' software RAID volume on four 5400RPM
> HDDs, right up to a giant hundreds-of-fast-disks monster filer full of
> dedicated ASICs and great gobs of battery backed write cache DRAM. Are
> you able to be any more specific about what you're dealing with?
>
>>
>> > > We are suing weblogic.
>> > ^^^^^
>> > Best. Typo. Ever.
>> >
>> > I hear most people who use it want to, you're just brave enough to
>> do it :-P
>> I wish I could make a few millions that way.
>>
>>
>> Thank you for all the replies. The first step is, of course, to
>> migrate the data. I am working with ora2pg for that. I assume
>> creating files with 'COPY' to work as input for PostgreSQL is the
>> right approach? We don't have many stored procedures or packages. So
>> that part should be OK.
>
>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: adarsh.sharma@orkash.com, ringerc@ringerc.id.au
Subject: Re: Parameters for PostgreSQL
In-Reply-To: <4E3A2AFD.1090106@orkash.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox