Skip site navigation (1) Skip section navigation (2)

Re: tablespaces and DB administration

From: pgsql(at)mohawksoft(dot)com
To: "Andreas Pflug" <pgadmin(at)pse-consulting(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: tablespaces and DB administration
Date: 2004-05-27 20:38:09
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> pgsql(at)mohawksoft(dot)com wrote:
>>As you can see, it takes a LOT longer. That's because the disk has to do
>> a
>>lot more work, the hardware data path has to carry twice as much data,
>> and
>>you have to manage multiple accesses to a single object, the disk.
>>It doesn't take much imagination to see what this would mean for pg_xlog.
> Well, writing off-reality benchmarks on hardware setups I'd never
> suggest for db server usage proves... what?
> Additionally, do you care about safety?
> Regards,
> Andreas

It was a demostration of the effect that multiple drives has. There is a
very real and measurable I/O bandwidth advantage to be gained by putting
concurrently accessed data on separate data channels. Any test that is
capable fo utilizing multiple I/O channels will show it.

This is not the place to really discuss this, and if you want to persue
this discussion, lets take it off line.

As for RAID5, it has its advantages, as does RAID0 and RAID3, and yes,
RAID1 and higher are pretty safe. A *good* RAID system goes for thousands
or tens of thousands of dollars. A 24x7 redundant storage system may not
be required by everyone. With new IDE with DMA interface cards, it should
be possible to create a very high performance system. A system which will
perform better if the pg_xlog is on a different disk than the data.

As for "do I care about safety?" Yes, yes I do, but "safe" and "paranoid"
are two different things. There is always a cost/benefit analysis for any
system. RAID5 and RAID3 are calculated risks. The bet is that no more than
one drive will fail at any one time. It is a good bet, but not 100%. I've
seen RAID systems have two drive failures at the same time, during the
auto-rebuild to the spare, a second drive dies. Game over.

Since RAID5 is a risk, maybe we should mirror, RAID0+1. That's a risk too,
what if the two mirrored drives die? Yikes, then you're screwed again.

If you want to be safe, you may want RAID5+1, where you mirror two RAID5
systems. That's really safe. You should have each RAID5 system on its own
controller with its own independent battery backed up redundant power
supply. That will be safe. Wait.. What about earth quakes? Shock mounted
racks. Lightning? Surge suppressors on the SCSI cables. Flood? Wrap it in
a zip-lock bag. Al Qaeda? Wrap it in a kevlar!!

There is a cost/benefit analysis for everything. RAIDs are very good and
reasonably safe devices, but the argument that the performance will be the
same as multiple individual disks (which are equivilent to the ones in the
RAID) preferably on different I/O channels is proveable nonsense and you
should know that.

In response to


pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2004-05-27 20:50:24
Subject: Re: SELECT * FROM <table> LIMIT 1; is really slow
Previous:From: Bruce MomjianDate: 2004-05-27 20:31:57
Subject: Win32, PITR, nested transactions, tablespaces

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group