Re: [QUESTIONS] Does Storage Manager support >2GB tables?
От | Chris Albertson |
---|---|
Тема | Re: [QUESTIONS] Does Storage Manager support >2GB tables? |
Дата | |
Msg-id | 35075710.819A122@topdog.logicon.com обсуждение исходный текст |
Ответ на | Re: [QUESTIONS] Does Storage Manager support >2GB tables? (The Hermit Hacker <scrappy@hub.org>) |
Список | pgsql-hackers |
The Hermit Hacker wrote: > > Redirected to 'the proper list' - pgsql-hackers@postgresql.org > > On Wed, 11 Mar 1998, Chris Albertson wrote: > > > Also, is anyone working on storage mangers? I was thinking that > > a raw partition manager would be good to have. Could be faster > > then one that uses the file system. Give it two partitions and > > it could do stripping and gain some real speed. > > stripping can be done from the operating system level to give you > that 'boost'...and Oracle, in fact, moved away from the raw partition > level to just using the Unix file system...I believe it would > overcomplicate the backend, and give a negligible boost in performance, if > we had to build a 'low level drive interface'... I know you must have looked at far more Postgresql code then I have but I was browsing the storage manager. Apparently it is fairly easy to assign a class to a manager as each class is tagged in the system catalog with a storage method. What I really want is a >2GB table. I was trying to see if this was supported by reading the source. Looks like it may be. The note in the To Do list includes testing. I would test it but for lack of disk space. (I'll have more in a while.) I need the >2GB feature bad enough that I'd implement it myself. My thought was that I may to easier to write a new manager then understand and fix a broken one. A manager is just given a class name and block number and told to either fetch or get it. (well not quite so simple but close). I don't think it needs to look inside the 8K (adjustable now) blocks. Anyway, if I wrote such a beast my real motivation would be to have big tables. Faster big tables would be just a plus. What I really hope for is that somebody else fixes the existing code :-) -- --Chris Albertson chris@topdog.logicon.com Voice: 626-351-0089 X127 Logicon RDA, Pasadena California Fax: 626-351-0699
В списке pgsql-hackers по дате отправления: