Re: [HACKERS] Re: [QUESTIONS] Does Storage Manager support >2GB tables?
От | ocie@paracel.com |
---|---|
Тема | Re: [HACKERS] Re: [QUESTIONS] Does Storage Manager support >2GB tables? |
Дата | |
Msg-id | 9803121854.AA29482@dolomite.paracel.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: [QUESTIONS] Does Storage Manager support >2GB tables? (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] Re: [QUESTIONS] Does Storage Manager support >2GB tables?
|
Список | pgsql-hackers |
Bruce Momjian wrote: > > > I have had the pleasure to work on the guts of one of the major databases > > raw partition storage managers over the last ten years (hint, not my > > current domain), and guess what? It implements a file system. And, not a > > particularly good filesystem at that. Think about something like "FAT", > > but not quite that nice. It was also a major source of pain in that it > > was complex, heavily concurrent, and any errors show up as massive data > > loss or corruption. Be careful what you wish for. > > Interesting. Perhaps we could: a) Incorporate an existing filesystem into the code (ext2?). By Incorporate, I mean that we would just take the latest version of the code and link it into the executable, or into a library and make calls to some of the lower level access and allocation routines. b) suggest that for higher performance, the user should format the disk partition with ext2 (or whatever) and turn off caching and set the block size to the maximum possible. I know for a fact that ext2 lets the user select the block size, and it looks like Linux at least supports a sync mount option which makes all I/O to this FS synchronous (which I assume would turn off write caching at least). If caching could be disabled, then option b would seem to provide performance equivalent to a. Ocie Mitchell
В списке pgsql-hackers по дате отправления: