Re: [pgsql-hackers-win32] Sync vs. fsync during checkpoint
От | Jan Wieck |
---|---|
Тема | Re: [pgsql-hackers-win32] Sync vs. fsync during checkpoint |
Дата | |
Msg-id | 4027F063.8020506@Yahoo.com обсуждение исходный текст |
Ответ на | Re: [pgsql-hackers-win32] Sync vs. fsync during checkpoint (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: [pgsql-hackers-win32] Sync vs. fsync during checkpoint
Re: [pgsql-hackers-win32] Sync vs. fsync during |
Список | pgsql-hackers |
Greg Stark wrote: > Jan Wieck <JanWieck@Yahoo.com> 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. # #================================================== JanWieck@Yahoo.com #
В списке pgsql-hackers по дате отправления: