Re: [HACKERS] Arbitrary tuple size

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