This makes sense to me. I sense a TODO item :-) (My dim and possibly incorrect memory of administering Ingres around 10 years ago was that it supported both raw devices and file system based databases. We opted for a file system base, for reasons others have mentioned here, but I seem to recall we used a raw device for the transaction log for performance reasons. But, as the saying goes, that was a long time ago, and in another country.)
andrew Tom wrote > "Andrew Dunstan" <[EMAIL PROTECTED]> writes: >> Is anyone seriously suggesting that postgres should support either raw >> devices or use some sort of virtual file system? If not, this whole >> discussion is way off topic. > > I have zero interest in actually doing it. However, it'd be nice if > the existing "storage manager" API were clean enough that our response > to this type of question could be "sure, go implement it, and when > you're done let us know what performance improvement you see". We've > allowed the smgr API to degenerate over the years. CREATE/DROP > DATABASE both bypass it, and the support for alternate database > locations messes up the API pretty thoroughly (not that there's > anything clean about that feature at all), and I think there are some > other issues with specific commands bypassing the smgr abstractions. > > I think it would be reasonable to fix this as part of the "tablespaces" > work that people keep wanting to do. > > regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]