As I offered some time to work on tuple chaining this thread clearly
touches the same area.
The idea of transparantly moving big attributes into a seperate table
clearly has its benefits as long as normal operations need not to touch
these long values. I (too) see this as a great deal. And the fact that
it happens transparently (not visible to user) is the best about it.
But AFAICS tuple chaining shouldn't be such a big deal, it should be
about three days of work. (It'll definitely take longer for me, since I
have to understand pgsql's internals first.): Split the tuple into
multiple Items on disk storage, concatenate them on read in. Then make
vacuum ignore continued items when not dealing with the whole tuple. No
need to touch CID, XID etc. The most obvious disadvantage is possible
fragmentation of tuples (unless handled in vacuum). Disk access
atomicity for tuples is a non issue for Linux people since Linux uses 1k
blocks :-(
Storing attributes seperately is the best solution once you exceed
4*BLKSZ, tuple chaining addresses 1.1-3*BLKSZ most efficiently. (correct
me if I'm wrong)
LONG as a seperate type is IMHO just another concept you have to master
before you can use a RDBMS efficiently. The less different concepts a
user needs to learn, the easier life is for him. Postgres already has a
lot of data types to learn.
Wrapping lo in a user type sounds good to me.
Yours Christof
