Re: [HACKERS] Arbitrary tuple size

At 10:12 9/07/99 +0900, Tatsuo Ishii wrote:
>
>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.

Much as the purist in me hates concept of hard links (as in Leon's suggestions), this *may* be a good application for them. Certainly that's how Dec(Oracle)/Rdb does it. Since most blobs will be totally rewritten when they are updated, this represents a slightly smaller problem in terms of MVCC.

>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.

Did you mean a table for each field? Or a table for each table (which may have more than 1 LO field). See comments below.

>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.

I would very much like to see the ability to have multi-file databases and tables - ie. the ability to store and table or index in a separate file. Perhaps with a user-defined partitioning function for table rows. The idea being that:

1. User specifies that a table can be stored in one of (say) three files.
2. When a record is first stored, the partitioning function is called to determine the file 'storage area' to use. [or a random selection method is used]

If you are going to allow LOs to be stored in multiple files, it seems a pity not to add some or all of this feature.

Additionally, the issue of pg_dump support for LOs needs to be addressed.

That's sbout it for me,

Philip Warner.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: +61-03-5367 7422 | _________ \
Fax: +61-03-5367 7430 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/