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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Re: indexing words slow
Следующее
От: Hal Snyder
Дата:
Сообщение: Re: [HACKERS] port/getrusage.c?