wieck@debis.com (Jan Wieck) writes:
> Another bonus would be this: What happens on an UPDATE to a
> table having LONG attributes? If the attribute is not
> modified, the OLD LongData will be found in the targetlist,
> and we'll not waste any space by storing the same information
> again.
Won't work. If you do that, you have several generations of the
"primary" tuple pointing at the same item in the "secondary" table.
There is room in the multiple primary tuples to keep track of their
committed/uncommitted status, but there won't be enough room to
keep track in the secondary table.
I think this can only work if there are exactly as many generations
of the LONG chunks in the secondary table as there are of the primary
tuple in the main table, and all of them have the same transaction
identification info stored in them as the corresponding copies of
the primary tuple have.
Among other things, this means that an update or delete *must* scan
through the tuple, find all the LONG fields, and go over to the
secondary table to mark all the LONG chunks as deleted by the current
xact, just the same as the primary tuple gets marked. This puts a
considerable crimp in your claim that it'd be more efficient than
a multiple-tuple-segment approach.
Of course, this could be worked around if the secondary table did *not*
use standard access methods (it could be more like an index, and rely on
the primary table for all xact status info). But that makes it look
even less like a clean data-type-based solution...
regards, tom lane