Greg Smith wrote: > 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. The counter-argument is that keeping the database software on the same drive will ensure you always run the same version in say a two node failover cluster. But that's a fairly specific use-case. For the general use-case, I agree with Greg's recommendation. >> So I am assured it is fast. > > Compared to what? The same amount spent on direct storage would be > widly faster. Counterpoint: SAN is already in place... > 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. As the guy who did much of the work on the Win32 port, I have to +1 this several times over ;-) PostgreSQL on Win32 will always be slower than it's on Unix, for architectural reasons. This difference can increase drastically under high load. These are facts, not just the general recommendation from Unix people to stay away from Windows, btw :-) >> 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. Say what? As long as your SAN guarantees an atomic snapshot of all your data (which every SAN I've ever heard of guarantees if you're on a single volume - entry level SANs often don't have the functionality to do multi-volume atomic snapshots, though), you don't need to set up PITR for simple backups, AFAIK. It's just simple crash recovery... It's still good idea, though, since it gives you the PIT part of PITR, which you don't get with just a snapshot. //Magnus
