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.

I am suggesting the longoid is not the oid of the primary or long*
table, but a unque id we assigned just to number all parts of the long*
tuple. I thought that's what your oid was for.

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

May as well. I can't think of a better solution for indexing when you
have long values. I don't think we want long* versions of indexes.

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026