The choices for Windows are much easier, because there's only one of them that makes sense for a database disk.
While generally deprecated at this point, it's still common for USB devices in particular to be formatted with the older FAT32 filesystem. Since FAT32 is not journaled, unclean shutdown requires running the chkdsk utility to recover from. Due to this and the lack of security on FAT32 files, the PostgreSQL installer does not support installing a database cluster directly onto a FAT32 volume. However, it's possible to install onto this filesystem if you manually run the initdb command after regular installation. However, this is not recommended for a reliable database configuration.
Microsoft's flagship filesystem is NTFS. This filesystem uses non-ordered metadata journaling, similar to the writeback journal mode on Linux. This is generally reliable, but on rare occasions you might run into a volume that cannot be mounted in Windows without running the old chkdsk utility in a special mode as part of booting the system.
As described earlier, PostgreSQL installations on Windows using NTFS should prefer to set the following in the database configuration:
open_datasync=fsync_writethrough
This configures the filesystem to flush its WAL writes through any volatile disk write caches.
It's possible to create the functional equivalent of a symbolic link on NTFS called a filesystem junction. The Junction utility available from http://www.microsoft.com/technet/sysinternals allows creating these. This lets NTFS volumes on Windows to relocate the pg_xlog or other parts of the database tree to another filesystem, and to use tablespaces too.
Theoretically you can create an NFTS volume of 16 TB using the default cluster size of 4 KB, the same limit as most Linux deployments. It's even straightforward to create a volume with larger clusters though; at 64 KB, NTFS might support 256 TB volumes instead. As noted at the beginning of this chapter, partitioning such large volumes on PC hardware requires you create a GUID Partition Table instead of using the older MBR approach, and that your version of Windows will understand the resulting partition scheme.
It's possible to turn on automatic compression of a NTFS volume, potentially valuable for the same reasons mentioned in the ZFS section. In practice, systems doing the sort of large queries that most benefit from this are not commonly practical on Windows anyway, due to its limitations in shared memory and connection capacity.
Similarly to the UNIX noatime parameter, it's possible to prevent NTFS from constantly updating when files were last accessed. Another useful tweak is to turn off the 8.3 filename generation that Windows does for backward compatibility with older applications. These behaviors are disabled like the following:
fsutil behavior set disablelastaccess 1 fsutil behavior set disable8dot3 1
Be careful when disabling the 8.3 filename generation in particular. One area this has been known to cause problems is if the %TEMP% or %TMP% environment variables are using the short filenames to access their files. You may need to update these variables to refer to the full pathname instead.