Re: [HACKERS] LONG

>
> > The solution I see is to give any out of line datum another
> > Oid, that is part of it's header and stamped into the
> > reference data. That way, the long attribute lookup can use
> > SnapshotAny using this Oid, there can only be one that
> > exists, so SnapshotAny is safe here and forces that only the
> > visibility of the master tuple in the main table counts at
> > all.
>
> This is a great idea. Get rid of my use of the attribute number. Make
> the varlena long value be:
>
> long-bit|length|longrelid|longoid|longlen
>
> No need for attno in there anymore.

I still need it to explicitly remove one long value on
update, while the other one is untouched. Otherwise I would
have to drop all long values for the row together and
reinsert all new ones.

> Having a separate oid for the long value is great. You can then have
> multiple versions of the long attribute in the long table and can
> control when updating a tuple.
>
> I liked Hiroshi's idea of allowing long values in an index by just
> pointing to the long table. Seems that would work too. varlena access
> routines make that possible.

Maybe possible, but not that good IMHO. Would cause another
index scan from inside index scan to get at the value. An we
all agree that indexing huge values isn't that a good thing
at all.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck(at)debis(dot)com (Jan Wieck) #