If we get wide tuples, we could just throw all large objects into one
table, and have an on it. We can then vacuum it to compact space, etc.
> Going toward >8k tuples would be really good, but I suspect we may
> some difficulties with LO stuffs once we implement it. Also it seems
> that it's not worth to adapt LOs with newly designed tuples. I think
> the design of current LOs are so broken that we need to redesign them.
>
> o it's slow: accessing a LO need a open() that is not cheap. creating
> many LOs makes data/base/DBNAME/ directory fat.
>
> o it consumes lots of i-nodes
>
> o it breaks the tuple abstraction: this makes difficult to maintain
> the code.
>
> I would propose followings for the new version of LO:
>
> o create a new data type that represents the LO
>
> o when defining the LO data type in a table, it actually points to a
> LO "body" in another place where it is physically stored.
>
> o the storage for LO bodies would be a hidden table that contains
> several LOs, not single one.
>
> o we can have several tables for the LO bodies. Probably a LO body
> table for each corresponding table (where LO data type is defined) is
> appropreate.
>
> o it would be nice to place a LO table on a separate
> directory/partition from the original table where LO data type is
> defined, since a LO body table could become huge.
>
> Comments? Opinions?
> ---
> Tatsuo Ishii
>
>
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026