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" <andrew@dunslane.net> 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