On Mon, 8 Sep 2008, William Garrison wrote:
2) We could install PostgreSQL onto the C: drive and then configure the data folder to be on the SAN volume (Z:)
Do that. You really don't want to get into the situation where you can't run anything related to the PostgreSQL service just because the SAN isn't available. You may have internal SAN fans that will swear that never happens, but it does. Also, it allows installing a later PostgreSQL version upgrade on another system and testing against the SAN data files in a way that said system could become the new server. There's all kinds of systems management reasons you should separate the database application from the database files.
So I am assured it is fast.
Compared to what? The same amount spent on direct storage would be widly faster.
The thing to remember about SANs is that they are complicated, and there are many ways you can misconfigure them so that their database performance sucks. Make sure you actually benchmark the SAN and compare it to direct connected disks to see if it's acting sanely; don't just believe what people tell you.
I personally can't understand why anybody would spend SAN $ and then hobble the whole thing by running PostgreSQL on Windows. The Win32 port is functional, but it's really not fast.
It is really nice because it supports instant snapshots so we can, in theory, snapshot a volume and re-mount it elsewhere.
You'll still need to setup basic PITR recovery to know you got a useful snapshot. See http://lethargy.org/~jesus/archives/92-PostgreSQL-warm-standby-on-ZFS-crack.html for a nice intro to that that uses ZFS as the snapshot implementation.
-- * Greg Smith gsmith@xxxxxxxxxxxxx http://www.gregsmith.com Baltimore, MD
