Jan Wieck <[EMAIL PROTECTED]> writes:
The whole sync() vs. fsync() discussion is in my opinion nonsense at this point. Without the ability to limit the amount of files to a reasonable number, by employing tablespaces in the form of larger container files, the risk of forcing excessive head movement is simply too high.
I don't think there was any suggestion of conflating tablespaces with implementing a filesystem in postgres.
Tablespaces are just a database entity that database stored objects like tables and indexes are associated to. They group database stored objects and control the storage method and location.
The existing storage mechanism, namely a directory with a file for each database object, is perfectly adequate and doesn't have to be replaced to implement tablespaces. All that's needed is that the location of the directory be associated with the "tablespace" of the object rather than be a global constant.
Implementing an Oracle-style filesystem is just one more temptation to reimplement OS services in the database. Personally I think it's an awful idea. But even if postgres did it as an option, it wouldn't necessarily have anything to do with tablespaces.
Doing this is not just what you call it. In a system with let's say 500 active backends on a database with let's say 1000 things that are represented as a file, you'll need half a million virtual file descriptors.
Jan
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org