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