Michael Samuel wrote:
>
> > Remember, general purpose file systems must do for files what Postgres is
> > already doing for records. You will always have extra work. I am seriously
> > thinking of trying a FAT32 as pg_xlog. I wonder if it will improve performance,
> > or if there is just something fundamentally stupid about FAT32 that will make
> > it worse?
>
> Well, for a starters, file permissions...
>
> Ext2 would kick arse over FAT32 for performance.
OK, I'll bite.
In a database environment where file creation is not such an issue, why would ext2
be faster?
The FAT file system has, AFAIK, very little overhead for file writes. It simply
writes the two FAT tables on file extension, and data. Depending on cluster size,
there is probably even less happening there.
I don't think that anyone is saying that FAT is the answer in a production
environment, but maybe we can do a comparison of various file systems and see if any
performance issues show up.
I mentioned FAT only because I was thinking about how postgres would perform on a
very simple file system, one which bypasses most of the normal stuff a "good"
general purpose file system would do. While I was thinking this, it occurred to me
that FAT was about he cheesiest simple file system one could find, short of a ram
disk, and maybe we could use it to test the assumptions about performance impact of
the file system on postgres.
Just a thought. If you know of some reason why ext2 would perform better in the
postgres environment, I would love to hear why, I'm very curious.
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])